Tim Mooney wrote:
> In regard to: Re: gimp 1.1.18, Garry R. Osgood said (at 9:16pm on Mar 24, 2000):
>
> >Philippe.Defert@xxxxxxx wrote:
> >
> >> <snipped...>
> >
> >> - on alpha-dec-osf4.0d, the program give all errors when loading
> >> plugins even though plugin does not crash::
> >>
> >> $ /usr/local/bin/gimp
> >>
> >> ** WARNING **: wire_read: error
> <snipped...>
> I've seen this at various times on all the alpha-dec-osf boxes I'ved tried
> compiling gimp on -- I think I may have been the first person to report it
> to the developer list. At various times I've thought the problem had been
> fixed by some change in the gimp, but I just tried 1.1.19 on a 5.0 box with
> patch set #1 last weekend, and the same thing happened. I have a 4.0f box
> that the problem doesn't happen for though.
>
> As I mentioned when I first reported this problem, it turns out that if you
> run the gimp under `trace' (just like truss) the first time you run the gimp,
> most of the plug-ins are queried successfully and work as expected thereafter.
> At that point, you can run gimp without tracing it, and the plugins work fine.
> It's only the first time through that this happens.
<snipped...>
We're definitely going to need help from people with DEC-osf boxes;
between you and Philippe, you've shot my favorite theory down - that
it was a peculiarity of the 4.0F compiler - and I have SGI here, and don't
see it, and most active developers have various flavors of Linux or Solaris
and they don't see it.
It's a fairly well understood truth that the out-of-box gimp actually
starts up the plug-in to invoke its query() function on run-up, but afterwards
a "mature" gimp reads up on plugins from a resource file. So if the resource
file gets built the first time, the problem won't occur subsequently - until
a new plug-in gets installed.
This leads to two ponder points:
1) the execution pathways on the gimp and plug-in side of the wire that
are unique to query don't get exercised much - nice place for bugs to persist.
2) When an out-of-box gimp is querying all of those plug-ins, a whole lot
of forking is going on - the OS is replicating the Gimp image into a new
process, then overlaying that image with the plug-in executable. Not a
trivial exercise. And it is happening RAT-TAT-TAT-TAT. Methinks
when you started tracing Gimp, you reduce an undiagnosed timing constraint
on sending messages between processes and the problem goes away. If fork
timing is an issue, then the isolated and relatively infrequent forks of plug-ins
likely do not trigger the mis-reading of messages on the wire and they behave
just fine.
If 2), then nothing bad is likely to be observed when single-stepping through
processes on both sides of the wire - near quiescent conditions - so a debugger
will likely not explicitly show anything. So one is led to ponder the architecture-
particular latencies that occur when a parent is forking off children in fairly
short order.
I'll give the aforementioned execution pathways a careful look this weekend,
and if something interesting suggests itself, I'll send -off-list mail to Tim
and other victims of #2742. Anyone with a DEC out there that wants to play in
this sandbox, come on in.
Be good, be well
Garry
