erating a stacktrace anyhow.
>
> You can get a backtrace if you run the process under debugger without
> dumping a core file. No special setup required. I was thinking to attach
> the debugger on SIGSEGV event. Is it too late? I see certain gnome apps
> failing and they ask you if
On Thu, Apr 11, 2002 at 05:21:24PM -0400, Kevin A. McGrail wrote:
> > Date: Fri, 12 Apr 2002 00:24:11 +0800
> > To: [EMAIL PROTECTED]
> > From: Stas Bekman <[EMAIL PROTECTED]>
> > Subject: Challenging things to do: SIGSEGV catcher and backtrace extractor
>
> Date: Fri, 12 Apr 2002 00:24:11 +0800
> To: [EMAIL PROTECTED]
> From: Stas Bekman <[EMAIL PROTECTED]>
> Subject: Challenging things to do: SIGSEGV catcher and backtrace extractor
> Message-ID: <[EMAIL PROTECTED]>
>
> A few moons ago we have discussed on
On Fri, 12 Apr 2002, Stas Bekman wrote:
> You can get a backtrace if you run the process under debugger without
> dumping a core file. No special setup required. I was thinking to attach
> the debugger on SIGSEGV event. Is it too late? I see certain gnome apps
> failing and the
and grabs the output.
>>1. Many users have problems getting the core file dumped
>
>
> then there'd be no way to automate generating a stacktrace anyhow.
You can get a backtrace if you run the process under debugger without
dumping a core file. No special setup required. I
On Fri, 12 Apr 2002, Stas Bekman wrote:
> If you read the rest of the post I mention it (without telling the name
> :). The problem with this module is that it's useful only after you have
> the core file. which is not good, because (as I've already explained):
it's important to mention Devel
Doug MacEachern wrote:
> On Fri, 12 Apr 2002, Stas Bekman wrote:
>
>
>>A few moons ago we have discussed on the dev list a tool for automatic
>>segfault detection (including multiple segfaults during 'make test') and
>>core backtrace generation. I'm quite frankly tired of explaining again
>>a
On Fri, 12 Apr 2002, Stas Bekman wrote:
> A few moons ago we have discussed on the dev list a tool for automatic
> segfault detection (including multiple segfaults during 'make test') and
> core backtrace generation. I'm quite frankly tired of explaining again
> and again that we need a core f
ped. Therefore it's
better to install a SIGSEGV to do the work. You will probably need to do
it in XS (could write a prototype with Inline). I think I've tried in
Perl and it didn't work (since SIGSEGV is caught on the C level by
httpd). If this works, you will be able to generate as
; apache dies with an SIGSEGV on loading.
>
> The error occured during the function call ParseStream() in Expat.pm.
> When i checked the core file with gdb i get this:
Scope this:
http://groups.yahoo.com/group/modperl/message/39557
So try switching to Apache 1.3.23 (the latest)?
Hope th
Hi list
I wrote a small perl module using perl/Expat for parsing XML-files.
With apache 1.3.19 and perl 5.6.0 and Expat 2.27 it works fine.
In my new configuration (apache 1.3.20, perl 5.6.1 and Expat 2.30)
apache dies with an SIGSEGV on loading.
The error occured during the function call
t; > various mod_perl archives, all to no avail.
> > >
> > > Symptom:
> > > ===
> > > SIGSEGV after fork(). Very reproducible. Memory corruption gets
moved
> > > around if the codebase changes.
> >
> > [ SNIP ]
> >
> >
ur best bet. I suspect you will find that you have some
> module doing something with XS or sockets or filehandles that can't deal
> with being forked.
That's just the thing with memory corruption:
Adding or removing random code causes the SIGSEGV signature to change
(or causes the
On Fri, Feb 15, 2002 at 11:44:03AM -0600, Fister, Mark wrote:
>
> > Dear mod_perl experts:
> >
> > Collectively, we've been at this for more than two weeks and have searched
> > various mod_perl archives, all to no avail.
> >
> > Symptom:
At 11:44 AM -0600 2/15/02, Fister, Mark wrote:
> > Dear mod_perl experts:
>>
>> Collectively, we've been at this for more than two weeks and have searched
>> various mod_perl archives, all to no avail.
>>
>> Symptom:
>> ===
>> SIGSEGV afte
> The only other way I can think of to solve this is to send my module list
> to this audience. Please find it, attached, with home-grown modules
> deleted.
Have you tried debugging the old-fashioned way, i.e. remove things until it
works? That's your best bet. I suspect you will find that you
> Dear mod_perl experts:
>
> Collectively, we've been at this for more than two weeks and have searched
> various mod_perl archives, all to no avail.
>
> Symptom:
> ===
> SIGSEGV after fork(). Very reproducible. Memory corruption gets moved
> around
On Thu, Feb 07, 2002 at 09:35:18PM +, Ged Haywood wrote:
> Hi there,
>
> On Thu, 7 Feb 2002, Fister, Mark wrote:
>
> > Tried that. Note: you also tried to help a fellow back in November of
> > 2001 on this VERY same stack trace.
> >
> > http://groups.yahoo.com/group/modperl/message/39560
>
Hi there,
On Thu, 7 Feb 2002, Fister, Mark wrote:
> Tried that. Note: you also tried to help a fellow back in November of
> 2001 on this VERY same stack trace.
>
> http://groups.yahoo.com/group/modperl/message/39560
Heh, didn't get very far with Lynx on that URL...
does anybody know what happ
On Thu, Feb 07, 2002 at 01:03:29AM +, Ged Haywood wrote:
> Hi there,
Hi! Thank you SOOO much for the reply!
[SNIP]
> You might try usemymalloc.
Tried that. Note: you also tried to help a fellow back in November of
2001 on this VERY same stack trace.
http://groups.yahoo.com/group/modperl
Hi there,
On Wed, 6 Feb 2002, Mark P. Fister wrote:
> Collectively, we've been at this for more than two weeks and have searched
> various mod_perl archives, all to no avail.
:(
> SIGSEGV after fork(). Very reproducible. Memory corruption gets moved
> around if the codeba
Dear mod_perl experts:
Collectively, we've been at this for more than two weeks and have searched
various mod_perl archives, all to no avail.
Symptom:
===
SIGSEGV after fork(). Very reproducible. Memory corruption gets moved
around if the codebase changes.
Tried:
=
* disable
> "Doug" == Doug MacEachern <[EMAIL PROTECTED]> writes:
Doug> On Tue, 3 Oct 2000, Bruce W. Hoylman wrote:
>>
>> Hello, Doug --
>>
>> Thanks for the reply.
>>
>> I have already applied this patch. The backtrace I provided was
>> producted by an httpd executable
On Tue, 3 Oct 2000, Bruce W. Hoylman wrote:
>
> Hello, Doug --
>
> Thanks for the reply.
>
> I have already applied this patch. The backtrace I provided was
> producted by an httpd executable with the perl_util.c patch already
> applied. The perl 5.6 patch from p5p was also in effect.
bruce
Hello, Doug --
Thanks for the reply.
I have already applied this patch. The backtrace I provided was
producted by an httpd executable with the perl_util.c patch already
applied. The perl 5.6 patch from p5p was also in effect.
The combined patches worked for the earlier CVS snapshot of modper
ns as expected. Both modperl revisions have the perl_util.c
> patch applied and perl 5.6 has been patched based on information from
> p5p regarding cop.h and threads. These patches solved an earlier
> SIGSEGV problem (similiar to this one?).
this looks exactly like the problem that s
perl 5.6 has been patched based on information from
p5p regarding cop.h and threads. These patches solved an earlier
SIGSEGV problem (similiar to this one?).
The particulars are included below.
Thanks for any insight.
modperl_20001003161843
apache-1.3_2911161201
(gdb) run -X -f /www/etc
On Mon, 11 Sep 2000, [iso-8859-1] François Chenais wrote:
> Hello
>
> I have a Segmentation fault error with mod perl !
> Any idea ?
> (gdb) run /opt/apache/lib/perl/WCM.pl
> Starting program: /usr/bin/perl /opt/apache/lib/perl/WCM.pl
...
> Program received signal SIGSEG
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x400e6865 in realloc () from /lib/libc.so.6
(gdb) where
#0 0x400e6865 in
29 matches
Mail list logo
