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 many backtraces
as the number of segfaults
2. during
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
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 was thinking to attach
the debugger on SIGSEGV event. Is it too late? I see certain gnome apps
failing
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 they ask you if you
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 the dev list a tool for automatic
segfault
the debugger on SIGSEGV event. Is it too late? I see certain gnome apps
failing and they ask you if you want to get the stack, without me doing
anything at all. That's what I want for modperl. You say it's not possible?
Sure, that's possible from the SEGV handler.
--
Daniel Jacobowitz
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
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 this helps! :)
--
\_/} Mark P. Fister
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.
[ SNIP ]
The above
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
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 after fork(). Very reproducible. Memory corruption gets moved
around
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:
===
SIGSEGV after fork(). Very reproducible. Memory
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 server to suddenly start working). I am nearly
certain
:
===
SIGSEGV after fork(). Very reproducible. Memory corruption gets
moved
around if the codebase changes.
[ SNIP ]
The above is the key: moved around. Therefore, I need Purify or similar
tool. I'm going to have to go this route, since nobody has any ideas.
Go go
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.
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
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
Heh,
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 rule
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 codebase changes.
[snip
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, maybe
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 should be solved by the patch i
sent you
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
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?).
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 SIGSEGV, Segmentation fault
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
25 matches
Mail list logo
