Date: 10/02/98
- Next message: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Previous message: seban <email protected>: "[PHP-DEV] Bug #810: Problem with a ms-sql memo field"
- Next in thread: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Reply: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Reply: Zeev Suraski: "Re: [PHP-DEV] 3.0.4 core dump"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.-- 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>
- Next message: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Previous message: seban <email protected>: "[PHP-DEV] Bug #810: Problem with a ms-sql memo field"
- Next in thread: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Reply: Shane Caraveo: "Re: [PHP-DEV] 3.0.4 core dump"
- Reply: Zeev Suraski: "Re: [PHP-DEV] 3.0.4 core dump"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

