Re: php4/phplib solved, maybe solaris bug...

Okay, further investigation... The core dump problem seems to be confined to my solaris box. On my linux box, phplib7 works without any problems after commenting out the aforementioned $. oddly enough, my home machine didn't get the empty query error, it worked fine... So now I'm wondering what is happening to others with phplib and php4? My linux box is running beta1 (I know...), the solaris box is running the latest cvs. As for the solaris machine, it is running Solaris6. Here's what gdb said... (gdb) run -X -DSSL Starting program: /home/web/apache/bin/httpd -X -DSSL Program received signal SIGFPE, Arithmetic exception. 0xef6283cc in .urem () from /usr/lib/libc.so.1 (gdb) bt #0 0xef6283cc in .urem () from /usr/lib/libc.so.1 #1 0xef0d0790 in zend_hash_find (ht=0x166478, arKey=0x142f70 "Query_ID", nKeyLength=9, pData=0xefffa9f4) at zend_hash.c:920 #2 0xef0b9ffc in execute (op_array=0x1e3d10) at zend_execute.c:215 #3 0xef0c0ab4 in execute (op_array=0x1e52c0) at zend_execute.c:1502 #4 0xef0c0ab4 in execute (op_array=0x1e6230) at zend_execute.c:1502 #5 0xef0c0ab4 in execute (op_array=0x1e66d8) at zend_execute.c:1502 #6 0xef0c0ab4 in execute (op_array=0x1f7e50) at zend_execute.c:1502 #7 0xef0c0ab4 in execute (op_array=0x11f170) at zend_execute.c:1502 #8 0xef0a050c in php_execute_script (primary_file=0xeffff2d8) at main.c:1197 #9 0xef0d85b8 in apache_php_module_main (r=0x112fe8, fd=27, display_source_mode=0) at sapi_apache.c:86 #10 0xef0d8c78 in send_php (r=0x112fe8, display_source_mode=0, filename=0x113918 "/home/web/wwws/gateway/index.php") at mod_php4.c:331 #11 0xef0d8cb4 in send_parsed_php (r=0x112fe8) at mod_php4.c:343 #12 0x20e0c in ap_invoke_handler () #13 0x3d23c in process_request_internal () #14 0x3d764 in ap_internal_redirect () #15 0xef480a48 in handle_dir () from /home/web/apache/libexec/mod_dir.so #16 0x20e0c in ap_invoke_handler () #17 0x3d23c in process_request_internal () #18 0x3d2bc in ap_process_request () #19 0x3101c in child_main () ---Type <return> to continue, or q <return> to quit--- #20 0x312a4 in make_child () #21 0x314a4 in startup_children () #22 0x31d88 in standalone_main () #23 0x32924 in main () Chad wrote: > > Wish I had good news! Maybe someone can offer some analysis... I've > narrowed the immediate problem down. > > First thing was that on line 36 in db_mysql.inc there was a dollar sign > that needed escaped, which got rid of the parse error. > > The next problem which other have observed is that hitting the pages > produces an empty query error. What I've tracked this down to is the > constructor for db_mysql.inc, which looks like: > > /* public: constructor */ > function DB_Sql($query = "") { > $this->query($query); > } > > basically it just executes a query if there is an argument. So what > happens is that the ct_sql.inc class calls on the database class to > create a new database object with the line > > $this->db = new $name; > > where $name is the database class. When it does this, it appears that > the constructor get's called and passed an empty query, which phplib > then tries to execute, resulting in the error. Now why PHP4 does this > and not PHP3 is something I haven't played around enough to discover, > maybe someone else knows offhand. Anyway, my quickie solution was to > modify the constructor so it looks like: > > /* public: constructor */ > function DB_Sql($query = "") { > if ($query != "") { > $this->query($query); > } > } > > Problem solved? Nope, now comes the real work! Fixing this got rid of > the empty SQL error, but now the server core dumps... And this is now > the task at hand. So maybe some of the knowledgable PHP4 folks can > suggest a course to proceed as the logs and a backtrace don't say much > at all. The error log shows: > > [Tue Oct 12 14:22:01 1999] [notice] child pid 13683 exit signal > Arithmetic Excep > tion (8) > [Tue Oct 12 14:23:13 1999] [notice] child pid 13706 exit signal > Segmentation Fau > lt (11) > [Tue Oct 12 14:23:19 1999] [notice] child pid 13685 exit signal > Segmentation Fau > lt (11) > > and dbx says: > > terminating signal 8 SIGFPE > > Which has to be the least helpfull error I've ever seen. That's all it > says, nothing else! Now maybe dbx is screwey, I'll try and get gdb > installed this afternoon and see what happens. > > But, if anyone has any other suggestions on tracking this down, I'd > appreciate it! > > -- > > Chad Cunningham > ccunning@math.ohio-state.edu > > Physicists think the real world models equations. > Engineers think equations model the real world. > Mathematicians fail to make the connection. > - > PHP3 Base Library Mailing List. Send messages to <phplib@lists.netuse.de>. > To unsubscribe, send "unsubscribe" to <phplib-request@lists.netuse.de> in > the body, not the subject, of your message. -- Chad Cunningham ccunning@math.ohio-state.edu Physicists think the real world models equations. Engineers think equations model the real world. Mathematicians fail to make the connection.