Tue, 7 Oct 2003 16:13:34 +0200
Is it true also for SIGPWR?
It is not just an issue with the debugger: it is generated
and kills the application even without the debugger.
I have no way to avoid redirect-malloc since
allocation is done with strdup and new that do not
expose a malloc() invocation.
----- Original Message -----
From: "Boehm, Hans" <email@example.com>
To: "'Giuseppe Attardi'" <firstname.lastname@example.org>; <email@example.com>
Sent: Friday, October 03, 2003 1:58 AM
Subject: [inbox] RE: [Gc] SIGPWR
> You should ignore those, and tell your debugger to simply pass them
> and let the program handle them.
> In its default configuration under Linux, with threads enabled, the
> sends and catches those signals to stop and restart threads during a
> However, you are likely to have problems with the combination of
> and threads. Dealing with that is on my list. The problem is that with
> the collecting allocator tends to get invoked during startup of the
> But it calls into pthreads for locks, etc. If you can do the malloc
> macros instead (so that the system startup code sees the system malloc),
> be far easier.
> > -----Original Message-----
> > From: Giuseppe Attardi [mailto:firstname.lastname@example.org]
> > Sent: Thursday, October 02, 2003 3:09 PM
> > To: email@example.com
> > Subject: [Gc] SIGPWR
> > I am trying to use the gc as a leak detector for a multithreaded
> > application,
> > on Linux RH 7.3 with gcc 2.96.
> > I have configured it with
> > configure --enable-full-debug --enable-redirect-malloc
> > --enable-threads=pthr
> > eads
> > and linked the program with .libs/libgc.a.
> > The program gets first
> > signal SIGPWR, Power fail/restart
> > and then
> > signal SIGXCPU, CPU time limit exceeded
> > What can I do?
> > -- Beppe
> > _______________________________________________
> > Gc mailing list
> > Gc@linux.hpl.hp.com
> > https://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc