Re: [Gimp-developer] Perl server problem
Dear Gimpers
Thanks for such a prompt reply --- when one is lost like the way I am
There is this wonderful mailing list
[What would I have done without internet :-(]
I had posted a question about -- which is the best way to start
gimp. [this was some time back].
I had received no reply then,
anyway this is how I start my gimp script.
[--enable-stack-trace {never|query|always} option is not available
in with gimp 1.1.04]
_
Xvfb :20
DISPLAY=godavari:20
export DISPLAY
gimp --display $DISPLAY --no-interface --version
$pth/gchart $ipdir $gifdir $pattern
_
and this is what the gchart looks like
**
#!/usr/bin/perl -w
use Gimp;
use Gimp::Fu;
use Fcntl;
#Gimp::set_trace(TRACE_ALL);
$Mainpath = /linuxfs/edp/cdhavse/chts;
require /opt/cmie/perl5mod/miscfunc.pl;
require $Mainpath/start;
require $Mainpath/drfunc;
require $Mainpath/charts_lib;
register
(
Gimp_Charts,
Gimp_Charts,
Pie and Bar Charts,
CDhavse,
Copyright 2000,
2000-06-12,
Toolbox/Xtns/Perl-Fu/Tutorial/chart,
*,
[
[PF_STRING, ptsdir, INPUT DIR,/tmpstore/anagram/out],
[PF_STRING, gifdir, OUTPUT DIR,/scratch/cdhavse/gifdir ],
[PF_STRING, pattern, PATTERN OF FILES TO BE PROCESSED,.*]
],
\start
);
exit main();
**
This is the strace -p -s o/p
#
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt, show
[S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt, show
[S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
#
Please suggest any changes that I should make.
There is this another issue about starting multiple sessions
of this script but let us sort out this problem first.
Thanks again
Chetan
On Tue, 5 Jun 2001, Marc Lehmann wrote:
On Tue, Jun 05, 2001 at 01:01:51PM +0530, Chetan Dhavse [EMAIL PROTECTED] wrote:
It happened again --- and here is the trace (strace) during the time when
hmm, this doesn't look like a bug in gimp (not directly, that is).
(2 sec. generated 15000 such lines) and Perl-Server shows 99% of CPU
used in the 'top'
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-..., 101) = 101
read(0, , 4096) = 0
this looks as if the perl-server outputs an error message and then tries
to read from stdin, which is... probably connected to /dev/null or so. How
do you start gimp the server? could you start in interactively (e.g.
inside a screen?) or re-run the strace with the -s switch, so we can
see the full error message (strace clips strings).
It's especially mysterious why it is trying to _read_ from stdin, my guess
is that this is (yet again) the endless-loop-in-libgimp bug.
You can test the latter by starting gimp with --enable-stack-trace never.
if the perl-server then dies immediately instead of sucking cpu time then
this is the problem you hit.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
On Wed, 06 Jun 2001, Chetan Dhavse wrote:
[...]
[--enable-stack-trace {never|query|always} option is not available in
with gimp 1.1.04]
[...]
This is the strace -p -s o/p
#
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt,
show [S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
write(1, /usr/lib/gimp/1.1/plug-ins/Perl-Server (pid:308): [E]xit, [H]alt,
show [S]tack trace or [P]roceed: , 99) = 99
read(0, , 4096) = 0
getpid()= 308
#
Please suggest any changes that I should make.
This shows that you are affected by the old bug related to the stack
trace: the process is stuck in an infinite loop trying to ask you if
you want a stack trace or not, but its input is not connected to
anything so it loops forever. This is why the --enable-stack-trace
option was introduced in the more recent versions of the Gimp. The
old version that you are using (1.1.4) did not have that option so it
will be very hard for you to know exactly what is wrong.
You have two options now:
- Upgrade to 1.2.1 (or to the current CVS version in the gimp_1_2
branch). This is the best solution because if you find any bugs in
that version, they can be fixed for everybody.
- If you really cannot upgrade to 1.2.x for some reason, then you
should at least recompile your old version and modify the part of
the code that asks if a stack trace should be produced. But it is
likely that the crash (generating the stack trace) is caused by a
bug that has been fixed since then. So even if you manage to find
where your script crashes, you will probably find that you have to
upgrade to a newer version in order to get rid of the bug that is
causing the crash.
-Raphael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
On 2 Jun, Sven Neumann wrote: I'd like to see your script or at least have a description of what it did so we can try to debug the behaviour you are describing. Using memprof it should be possible to find your leaks. The last time I checked GIMP with memprof it didn't show any unexpected leaks (means: no leaks in GIMP code) over a session of 2 hours. However it would make sense to me to retry with a session of tigert or some complex script. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
Hi, Marc Lehmann [EMAIL PROTECTED] writes: It's simple: i had(!) a script which loaded and analyzed thousands of (checked) jpegs and (unchecked) gifs. Broken gifs tend to hurt gimp badly, with effects ranging from gimp filling all virtual memory to segfaulting (and yes, sometimes cycling in the signal-catching code which, AFAIR, we agreed to disable in 1.2). you are aware that there's a command-line option to control the stack-trace behaviour? I'd like to see your script or at least have a description of what it did so we can try to debug the behaviour you are describing. Using memprof it should be possible to find your leaks. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
On 2 Jun 2001, Sven Neumann wrote: Hi, Marc Lehmann [EMAIL PROTECTED] writes: It's simple: i had(!) a script which loaded and analyzed thousands of (checked) jpegs and (unchecked) gifs. Broken gifs tend to hurt gimp badly, with effects ranging from gimp filling all virtual memory to segfaulting (and yes, sometimes cycling in the signal-catching code which, AFAIR, we agreed to disable in 1.2). you are aware that there's a command-line option to control the stack-trace behaviour? True enough. Besides, if we had a bug report filed for everything we wanted or thought we'd have in 1.2, we'd have to open up another whole development branch. :) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
On Sat, Jun 02, 2001 at 12:54:23AM +0200, Sven Neumann [EMAIL PROTECTED] wrote:
you are aware that there's a command-line option to control the stack-trace
behaviour?
yes.
I'd like to see your script or at least have a description of what it did
the inner loop was this (i cannot run it at the moment, though, since it
is part of a quite complex environment).
... for(many images)
my $img = Gimp-file_load(($_)x2);
$img-flatten;
eval { $img-convert_grayscale };
my $l = ($img-get_layers)[0];
$l = $l-gimp_scale(1, 0, 0, $s+0.4, $s+0.4);
$l-plug_in_c_astretch;
$l-width == $s or die $s .$l-width;
$l-height == $s or die $s .$l-height;
my $pr = new PixelRgn $l, 0,0,$s,$s, 0,0;
$pr = $pr-get_rect(0,0,$s,$s)-slice((0))-clump(2)-short;
(($pr *= $b-1) += 127) /= 255; #/ # vim can't correctly hilight this :(
$pr = $key-index($pr-list);
$img-delete;
What it does is load an image, scale it down quite a bit and create a
spatial index key.
I can send you the whole script, but to make sense you would need to
massage it quite a bit. If I could have made it small and simple I would
have sent it in long ago ;)
so we can try to debug the behaviour you are describing. Using memprof it
should be possible to find your leaks.
yes :/
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
On Thu, May 24, 2001 at 02:11:54PM +0530, Chetan Dhavse [EMAIL PROTECTED] wrote: I am using Gimp 1.1.4(I find this version more stable) same here.. gimp-1.2 has big stability and memory problems when it encounters lots of images in succession. The problem is the programs just hangs after making 200/300 charts. I think the problem is with the perl server, The program stops after the '%CPU used' shows 95% (of top) for the perl server. could it be that gimp closes the pipe and the perl-server tries to send commands but never can (it's not programmed to catch every case, to make it as fast as possible). Could you strace the pelr-server when that happens again and send me an excerpt (just strace -p pid)? If I start two instances of this program the top shows two perl servers. is this right? depends. you can configure the behaviour by setting the GIMP_HOST environment variable (perldoc Gimp::Net) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
