There is no "Logo maker" script. Please specify more
precicely which script you mean.

> In the script-Fu under Xtns there is a logo maker and whenever I use
> certain ones GIMP crashes.

Please respond to bugzilla mails using the bugzilla web interface.

What we need to know is which script *exactly* fails and
what are the error messages it procuces (if any).

> The script that fails is the plug_in_sparkle the error message says:
>
> Script-Fu Error while executing
> (script-fu-t-o-p-logo "The GIMP"
> 100.000000"-*-becker-*-r-*-*-24-*-*-*"0.200000 2.000000 FALSE '(0 40
0) '(255 255 255))
>   (plug_in_sparkle 1 17 81 0.03 0.49 481 6 15 1 0 0 0 0 0 0 0)

Again: please do NOT respond by mail to bugzilla mails. Every email
you receive from bugzilla is telling you this.

Thanks, I just tried the script under linux and it works
without an error. Anybody out there who can confirm this bug?

Sorry, but plug_in_sparkle is not a script. Can you please add a
comment to the bug report explaining what script you are running.
Please tell us exactly what menu entry you choose to run the script.

Under Xtns...Script-Fu....Logos...Particle Trace, when I use this it
gets to the end of sparkaling and then it crashes, and I never noticed
but when GIMP crashes, the command propmt and another GIMP message box
shows up sayng that script-fu has crshed and that it the dying script
might have damaged GIMP's internal state or something like that.

This script works fine for me. Tested with gimp-1.2.5 and gimp-2.0pre2.

Do you use the default script settings or any special parameters?

No I just start GIMP, i'm not a wiz at this stuff, I just like to see
what I can do, so try and speak english for me.

I use the default script seetings, I don't fool around with stuff I
don't really understand

Uhm, why did you close this report?

becuase I fixed the problem. got GIMP 2.0pre2 and GTK 2.2.4 and
everything works great

I can confirm this problem with 1.2.5 on Windows. Strangely the wrong 
parameters message appears *after* the sparkle plug-in terminates. 
This is apparently fixed in the 1.3+ series, though, and since it's 
very unlikely that more versions in the 1.2 series are released, it 
doesn't make much sense to accept further bugs reported against it.

What is strange about the message appearing after the plug-in dies?
The message seems to be printed in response to the death of the
sparkle plug-in. It's not about wrong parameters or is it?

Changing the state from UNCONFIRMED to NEW since Pedro confirmed the bug.

Won't be fixed in 1.2 and works in 2.0. Closing as WONTFIX.

The Particle Trace script does exhibit some oddities on Win32 also 
with a relatively fresh HEAD GIMP. When it gets to the "Sparkling.." 
phase, although the one and same "sparkle" process is running all the 
time, I get a GIMP Message dialog with the "Plug-In crashed" message, 
and the repeat counter increases all the time. Mitch or Sven, any 
idea what might cause this, where to start looking? 

(Still, the script does produce the desired kind of logo, AFAICS.)

The warning comes from app/plug-in/plug-in.c (plug_in_recv_message)
which is invoked on any of G_IO_IN | G_IO_PRI | G_IO_ERR | G_IO_HUP
on the GIOChannel *from* the plug-in.

For G_IO_ERR | G_IO_HUP the plug-in is killed and the message
is always displayed. For G_IO_IN | G_IO_PRI the message is only
shown if there was nothing to read from the pipe.

These conditions IMHO clearly indicate the plug-in has crashed,
given they are delivered correctly, so I guess these is some bug
in the win32 GIOChannel code.

Btw, does this occur with both gtk 2.2 and 2.4?

Turns out that on Win32 for some reason plug_in_recv_message() is 
sometimes called with none of the GIOCondition bits set... This 
happens both with GTK+ and GLib 2.4, and GTK+ and GLib 2.2. It is 
some misfeature in the Win GIOChannel code. (This might not be 
related at all to the original issue for GIMP 1.2.x in this bug 
report, sorry for reopening...) Will open a separate bug for GLib.

As a workaround to avoid the misleading error messages, would it be 
OK to add a (Win32-only) check in plug_in_recv_message() for zero 
condition and return right away in that case?

Sure, just add this workaround please.

And I like the "misfeature" euphemism btw. Will add
that to my list of words ;)

Workaround added, closing now hopefully for good. The GLib bug is bug 
#137968