You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Taneli Saastamoinen <ts...@cs.Helsinki.FI> on 2004/02/18 21:01:30 UTC

Apache 1.3.29 + Rivet 0.3: segfault

It just occurred to me that there's an actual Rivet developers mailing
list too, so I'm resending this here. Sorry for possible duplicates.

---------- Forwarded message ----------
Date: Wed, 18 Feb 2004 21:51:57 +0200 (EET)
From: Taneli Saastamoinen <ts...@cs.Helsinki.FI>
To: users@httpd.apache.org
Subject: Apache 1.3.29 + Rivet 0.3: segfault


Hi, I'm using Apache 1.3.29 and Rivet 0.3.0. Both are self-compiled with
gcc 2.95.4 (Debian stable).

The problem is that Rivet causes a seg fault when I try to use the
"parse" command, as in:

------
lobotomy:~/w/root$ cat test.rvt 
<?
parse [file join [file dirname [info script]] test-inc.rvt]
puts "<h1>index, still in code</h1>"
?>
<h1>index, not in code</h1>

lobotomy:~/w/root$ cat test-inc.rvt 
<h1>begin header</h1>
<?
puts "<h1>code in header</h1>"
?>
<h1>end header</h1>

lobotomy:~/w/root$ 
------

This produces:

------
<h1>begin header</h1>
<h1>code in header</h1>

<h1>end header</h1>
------

And:

------
lobotomy:~/kama/apache-install/bin$ tail -1 ../logs/error_log 
[Wed Feb 18 21:32:49 2004] [notice] child pid 21881 exit signal Segmentation fault (11)
lobotomy:~/kama/apache-install/bin$ 
------

When I try to run "gdb ./httpd", then "run -X", then hit the page, I get
this:

------
lobotomy:~/kama/apache-install/bin$ gdb ./httpd 
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) run -X
Starting program: /home/lobotomy/kama/apache-install/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x080fd444 in ?? ()
Cannot access memory at address 0x203040
(gdb) backtrace
#0  0x00000000 in ?? ()
#1  0x080fd444 in ?? ()
Cannot access memory at address 0x203040
(gdb) backtrace full
#0  0x00000000 in ?? ()
No symbol table info available.
#1  0x080fd444 in ?? ()
No symbol table info available.
Cannot access memory at address 0x203040
(gdb) 
------

Apache and Rivet should both be compiled with debugging symbols; I used
CC="gcc -g" ./configure --prefix=/home/lobotomy/kama/apache-install with
Apache and included -enable-symbols in the configure options with Rivet.
Neither binary (bin/httpd and libexec/mod_rivet.so) is stripped, and
both have a lengthy list of symbols when I look at them with "nm -a".

When I use gdb to set a breakpoint at ap_process_request, then "run -X",
then hit the page, then use "s" to step forward (several hundred times),
I get the following right before the seg fault:

------
ap_invoke_handler (r=0x80fc4fc) at http_config.c:495
495         int result = HTTP_INTERNAL_SERVER_ERROR;
(gdb) 
497         if (r->handler) {
(gdb) 
502             handler = r->content_type ? r->content_type : 
ap_default_type(r);
(gdb) 
503             if ((p = strchr(handler, ';')) != NULL) { /* MIME type 
arguments */
(gdb) 
509                 handler_len = strlen(handler);
(gdb) 
515         for (handp = handlers; handp->hr.content_type; ++handp) {
(gdb) 
516             if (handler_len == handp->len
(gdb) 
518                 result = (*handp->hr.handler) (r);
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0x080fd424 in ?? ()
Cannot access memory at address 0x203040
(gdb) backtrace
#0  0x00000000 in ?? ()
#1  0x080fd424 in ?? ()
Cannot access memory at address 0x203040
(gdb) 
------

So it seems that Rivet is causing Apache to crash somehow with the parse
command?

I asked David Welton (Rivet developer) about it, and he told me it works
fine with him ... I don't know why the backtrace doesn't work better, so
this is approximately all the info I have about this.

It might be that this is only a configuration issue or whatever, but I
haven't had any success with tweaking any config files, or anything else
for that matter. Any ideas appreciated...

-- 
my rite is to live and do


---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Apache 1.3.29 + Rivet 0.3: segfault

Posted by "David N. Welton" <da...@dedasys.com>.
I *HATE* this bug with a passion.  It's what I thought it was, namely
that Tcl gets compiled like so:

davidw@burns:~/download/tcl8.4.5/unix$ objdump -T libtcl8.4g.so  | grep stat
00000000      DF *UND*  00000197  GLIBC_2.2   __xstat64
00000000      DF *UND*  00000197  GLIBC_2.2   __lxstat64

And Apache like so:

davidw@burns:~/install/bin$ objdump -t httpd  | grep stat
0804efe0       F *UND*  000002fb              __xstat@@GLIBC_2.0
0804f090       F *UND*  000002fb              __fxstat@@GLIBC_2.0
0804f0f0       F *UND*  000002fb              __lxstat@@GLIBC_2.0

This means that something along the way attempts to squeeze a struct
that is too big into a small space, and crunch, there goes the stack.
Makes it very hard to trace down:-/

The immediate solution is to compile Apache with stat64 support as
well:

export EXTRA_CFLAGS="-D_FILE_OFFSET_BITS=64" then do configure, and
make.

What we really need is a configure system that is able to examine the
Tcl and Apache setups to determine how they've been compiled, and if
there is a mismatch, to scream very loudly and stop!

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: Apache 1.3.29 + Rivet 0.3: segfault

Posted by "David N. Welton" <da...@dedasys.com>.
Taneli Saastamoinen <ts...@cs.Helsinki.FI> writes:

> It just occurred to me that there's an actual Rivet developers
> mailing list too, so I'm resending this here. Sorry for possible
> duplicates.

Thanks, I do prefer that Rivet related correspondence goes here:-)
 
> ------
> 
> Apache and Rivet should both be compiled with debugging symbols; I used
> CC="gcc -g" ./configure --prefix=/home/lobotomy/kama/apache-install with
> Apache and included -enable-symbols in the configure options with Rivet.
> Neither binary (bin/httpd and libexec/mod_rivet.so) is stripped, and
> both have a lengthy list of symbols when I look at them with "nm -a".
> 
> When I use gdb to set a breakpoint at ap_process_request, then "run -X",
> then hit the page, then use "s" to step forward (several hundred times),
> I get the following right before the seg fault:
> 
> ------
> ap_invoke_handler (r=0x80fc4fc) at http_config.c:495
> 495         int result = HTTP_INTERNAL_SERVER_ERROR;
> (gdb) 
> 497         if (r->handler) {
> (gdb) 
> 502             handler = r->content_type ? r->content_type : 
> ap_default_type(r);
> (gdb) 
> 503             if ((p = strchr(handler, ';')) != NULL) { /* MIME type 
> arguments */
> (gdb) 
> 509                 handler_len = strlen(handler);
> (gdb) 
> 515         for (handp = handlers; handp->hr.content_type; ++handp) {
> (gdb) 
> 516             if (handler_len == handp->len
> (gdb) 
> 518                 result = (*handp->hr.handler) (r);
> (gdb) 
 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000 in ?? ()
> (gdb) where
> #0  0x00000000 in ?? ()
> #1  0x080fd424 in ?? ()
> Cannot access memory at address 0x203040
> (gdb) backtrace
> #0  0x00000000 in ?? ()
> #1  0x080fd424 in ?? ()
> Cannot access memory at address 0x203040
> (gdb) 
> ------

> So it seems that Rivet is causing Apache to crash somehow with the
> parse command?

Ok, what is really weird about this is that the crash is not happening
in 'parse', it is happening before the page is even hit.  You are sure
that changing the script causes this to not happen?  What appears to
be happening is that 

const handler_rec rivet_handlers[] =
{
    {"application/x-httpd-rivet", Rivet_SendContent},
    {"application/x-rivet-tcl", Rivet_SendContent},
    {NULL}
};

is being overwritten somehow, and Rivet_SendContent is somehow equal
to 0x0... *bang*.

> I asked David Welton (Rivet developer) about it, and he told me it
> works fine with him ... I don't know why the backtrace doesn't work
> better, so this is approximately all the info I have about this.

> It might be that this is only a configuration issue or whatever, but
> I haven't had any success with tweaking any config files, or
> anything else for that matter. Any ideas appreciated...

I would appreciate it others could test out his script.

Can you post your exact configurations for Apache and Tcl?  I have a
Debian stable machine that I can test it on.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org