Re: [PHP-DEV] 3.0.4 core dump From: Shane Caraveo (shane <email protected>)
Date: 10/02/98

matthew mcglynn wrote:
>
> I've moved this thread to the dev list because I think
> it's of limited appeal. I have not reported a bug yet because
> I believe I have not collected quality data on the crash.
>
> Me:
>
> > >This time I built PHP with debugging, so I'm hoping this
> > >core file will be of some use to someone.
>
> Zeev:
>
> > It might be if you make use of it :) You should generate a gdb backtrace
> > and send it to us at php-dev <email protected>, or better yet, submit a bug
> > report on http://ca.php.net/bugs.php3.
> >
> > To generate a backtrace, run
> > gdb /path/to/php/cgi /path/to/corefile
> > and at the gdb prompt type
> > (gdb) bt
>
> I'm happy to do this but unfortunately something is amiss. I
> think I stripped the binary before I installed it. This would
> make a backtrace sort of useless, wouldn't it ? How is
> stripping related to compiling with debug symbols (if at all) ?
>
> My do-conf for this binary:
> ./configure
> --with-gd=no
> --with-mysql=/usr/local/mysql
> --with-config-file-path=/usr/local/apache/etc
> --enable-track-vars=yes
>
> The lack of "--enable-debug=no" would indicate that the
> binary was built with debugging, right ? gdb complains
> of no debugging symbols, which is due to the fact that I
> stripped the binary I guess.
>
> Even so, I rebuilt the binary and ran it (unstripped)
> against this core file and it generated the following
> trace -- which I realize may be bogus because the binary
> has changed. For now it's all I've got -- if it core dumps
> again tonight I'll have better info.
>
> warning: exec file is newer than core file.
> Core was generated by `cardbot.php3'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x209ab in _php3_hash_find (ht=0xa7fa4, arKey=0x0, nKeyLength=18, pData=0xefbfd000) at php3_hash.c:834
> 834 HANDLE_NUMERIC(arKey, nKeyLength, _php3_hash_index_find(ht,idx,pData));
> (gdb) bt
> #0 0x209ab in _php3_hash_find (ht=0xa7fa4, arKey=0x0, nKeyLength=18, pData=0xefbfd000) at php3_hash.c:834
> #1 0xe1ea in phpparse () at control_structures_inline.h:848
> #2 0x1f01a in php3_parse (yyin=0xa5d24) at main.c:1461
> #3 0x1faa5 in main (argc=3, argv=0xefbfdefc) at main.c:1769
>
> That's all it gives me. I haven't used gdb in 6 years so
> if there's more I can do, please let me know.
>
> > What kind of script is it? Can you run it and see if it crashes on every
> > run? About the -lpthread issue, it's unclear whether it should affect the
> > CGI or not. It will clearly be removed completely in 3.0.5.
>
> The script performs a variety of database admin tasks. This
> is the nightly batch script for a large "digital postcard"
> website, so this script is searching for unsent cards (in
> a MySQL table) and generating lots of emails.
>
> It does not crash on every run -- I ran it 5 minutes after
> it core dumped and it completed the task. Of course, the first
> (partial) run had changed the db, so the second run was not
> duplicating any effort, or even necessarily running the same
> code, depending on where it died the first time.
>
> --
> matt.

Ok, it's certainly not the bug I fixed, it would have happened we module
shutdown, not php3_parse.

Shane 

--
PHP Development Mailing List   http://www.php.net/
To unsubscribe send an empty message to php-dev-unsubscribe <email protected>
For help: php-dev-help <email protected>