Jarkko Hietaniemi [EMAIL PROTECTED] writes:
I'm grasping at straws, and I really don't know much about
PerlIO... but try this:
//depot/perl/perlio.c#179 - /u/vieraat/vieraat/jhi/pp4/perl/perlio.c
Index: perl/perlio.c
--- perl/perlio.c.~1~ Thu Jun 13 20:05:05 2002
+++ perl/perlio.c
Doug Maceachern [EMAIL PROTECTED] writes:
patch below also cures (when calling system() with Apache::Upload handles
still alive). seems PerlIO_importFILE() should have a mode argument,
It did but nobody used it and now we have legacy.
The thing that world passes as 0 was suppoed to be O_READ
On Wed, 12 Jun 2002 23:45:41 +0200, [EMAIL PROTECTED] (Andreas J. Koenig)
said:
Currently I have a testcase that is still 7300 lines of perl code for
the server (after all these are in one file) but only 50 lines for the
client. I hope to cut that down to a reasonable size tomorrow.
On Thu, Jun 13, 2002 at 06:52:13PM +0200, Andreas J. Koenig wrote:
On Wed, 12 Jun 2002 23:45:41 +0200, [EMAIL PROTECTED] (Andreas J.
Koenig) said:
Currently I have a testcase that is still 7300 lines of perl code for
the server (after all these are in one file) but only 50 lines for
On Thu, 13 Jun 2002, Andreas J. Koenig wrote:
this might be worth a try. since the segv is something stdio, must be one
of std{out,err} getting corrupted somehow. ap_error_log2stderr does
this:
API_EXPORT(void) ap_error_log2stderr(server_rec *s) {
if ( s-error_log != NULL
On Thu, 13 Jun 2002, Andreas J. Koenig wrote:
Program received signal SIGSEGV, Segmentation fault.
0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43
43 iofflush.c: No such file or directory.
(gdb) bt
#0 0x400ed761 in _IO_fflush (fp=0x877f1e0) at iofflush.c:43
also, if possible
On Thu, Jun 13, 2002 at 08:26:30PM +0200, Andreas J. Koenig wrote:
On Thu, 13 Jun 2002 10:32:01 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED]
said:
On Thu, 13 Jun 2002, Andreas J. Koenig wrote:
Program received signal SIGSEGV, Segmentation fault.
0x400ed761 in _IO_fflush
_IO_read_end = 0x646e4128 Address 0x646e4128 out of bounds,
_IO_read_base = 0x73616572 Address 0x73616572 out of bounds,
_IO_write_base = 0x202e4a20 Address 0x202e4a20 out of bounds,
_IO_write_ptr = 0x6eb6c34b Address 0x6eb6c34b out of bounds,
_IO_write_end =
seems to be an Apache::Request issue with perlio. i can get a similar
segv with the modperl test change below.
system() triggers a PERL_FLUSHALL_FOR_CHILD; with the Apache::Upload
filehandles still alive. there is some ugly code to import the FILE* from
ApacheUpload_fh to a PerlIO, which
also note that the problem goes away if PERL_FLUSHALL_FOR_CHILD happens
after the Apache::Upload handles have gone out of scope. the change below
does not trigger and segvs, all tests pass. andreas, you could try to
make sure your Apache::Upload handles have gone out of scope (or are
patch below also cures (when calling system() with Apache::Upload handles
still alive). seems PerlIO_importFILE() should have a mode argument, in
this case we only want to allow reading on the given FILE*
--- Request/Request.xs~ Sun Jan 20 09:27:35 2002
+++ Request/Request.xs Thu Jun 13
On Thu, Jun 13, 2002 at 09:36:42PM +0300, Jarkko Hietaniemi wrote:
On Thu, Jun 13, 2002 at 08:26:30PM +0200, Andreas J. Koenig wrote:
On Thu, 13 Jun 2002 10:32:01 -0700 (PDT), Doug MacEachern
[EMAIL PROTECTED] said:
On Thu, 13 Jun 2002, Andreas J. Koenig wrote:
Program received
On Thu, 13 Jun 2002 15:11:04 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED]
said:
patch below also cures (when calling system() with Apache::Upload handles
still alive).
Thank you so much, Doug. Your diagnostics confirmed: the upload
filehandle was still in scope. The fix to Request.xs
On Thu, Jun 13, 2002 at 11:22:46PM +0300, Jarkko Hietaniemi wrote:
_IO_read_end = 0x646e4128 Address 0x646e4128 out of bounds,
_IO_read_base = 0x73616572 Address 0x73616572 out of bounds,
_IO_write_base = 0x202e4a20 Address 0x202e4a20 out of bounds,
_IO_write_ptr =
On Wed, 12 Jun 2002 17:18:53 +0100, Nick Ing-Simmons
[EMAIL PROTECTED] said:
Is this apache running multi-threaded? or just serially ?
So far only tested with -Dusemultiplicity -Duseperlio.
IIRC the back trace the SEGV was in stdio rather than in perl itself,
suggesting that
PAUSE is suffering from a SEGV since I installed RC1. After I upgraded
yesterday to snapshot 17165 I finally caught the following within gdb.
I'd appreciate further instructions where to go from here.
Program received signal SIGSEGV, Segmentation fault.
0x400d05ff in _IO_fflush (fp=0x89e4178) at
On Tue, 11 Jun 2002, Andreas J. Koenig wrote:
PAUSE is suffering from a SEGV since I installed RC1. After I upgraded
yesterday to snapshot 17165 I finally caught the following within gdb.
I'd appreciate further instructions where to go from here.
test case?
#4 0x816fc96 in Perl_my_popen
As Jarkko and Nick have pointed out, line numbering is off. I cannot
find out why this is the case, the sources *are* from 17165 as I can
verify via Apache::Status.
On Tue, 11 Jun 2002 08:23:18 -0700 (PDT), Doug MacEachern [EMAIL PROTECTED]
said:
doug On Tue, 11 Jun 2002, Andreas J. Koenig
18 matches
Mail list logo
