Bug #13174 Updated: SIGABRT when starting iPlanet

ID: 13174 Updated by: sniper Reported By: aki.hakkila@sonera.com Old Status: Open Status: Feedback Bug Type: iPlanet related Operating System: Solaris 2.6 PHP Version: 4.0.6 New Comment: So are there any problems with the latest snapshot or not? Previous Comments: ------------------------------------------------------------------------ [2001-09-10 05:28:31] aki.hakkila@sonera.com Oops, sorry ignore the last comment about setting status and headers.. The correct procedure seems to be in sapi_nsapi_send_headers. ------------------------------------------------------------------------ [2001-09-10 05:11:29] aki.hakkila@sonera.com iPlanet 4.1 php4-200109062235 seems to work. Still getting funny error messages when requesting non-existant php script. Warning: Failed opening '/path/to/document/root/somescript.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 I suppose iPlanet expects the Service SAF to handle errors (ie. setting http status). Seems to me that the NSAPI module should first call protocol_status with correct status code, then protocol_start_response and then write any data and return correct result code (which in case of Not Found error, for example, should be REQ_ABORTED instead of REQ_EXIT, IMHO). http://docs.iplanet.com/docs/manuals/enterprise/41/nsapi/04_mysaf.htm#14969 ------------------------------------------------------------------------ [2001-09-06 11:37:01] sniper@php.net Could you please try the latest CVS snapshot of PHP: http://snaps.php.net/ since the thread stuff was redone recently. Also, what version of iPlanet is this? --Jani ------------------------------------------------------------------------ [2001-09-06 09:40:37] aki.hakkila@sonera.com ./configure --with-nsapi=/path/to/iplanet --enable-libgcc --with-gnu-ld --with-debug PHP NSAPI module crashes during Init. --- (gdb) bt #0 0xef184d34 in __sigprocmask () #1 0xef17ba5c in _resetsig () #2 0xef17b1a4 in _sigon () #3 0xef17dff8 in _thrp_kill () #4 0xef0ba608 in abort () #5 0xeed82c5c in ts_resource_read (thread_resources=0x0, id=1387488) at TSRM.c:319 #6 0xeed82c2c in ts_resource_ex (id=0, th_id=0x15daa8) at TSRM.c:302 #7 0xeece1414 in php4_init (pb=0x0, sn=0x0, rq=0x0) at nsapi.c:494 #8 0xef6651dc in __0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP6HSessionP6HRequest () #9 0xef6647fc in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () #10 0xef664aa8 in INTfunc_exec () #11 0xef662318 in INTconf_run_late_init_functions () #12 0xef68f6ac in __0oRDaemonProcessorUXctv () #13 0xef695564 in __0fPDaemonProcessorSNewDaemonProcessorvT () #14 0xef6918d4 in daemon_run () #15 0x2f4e0 in main () --- Is the TSRM really supposed to use pthread -functions and data structures with iPlanet instead of NSAPI equivalents? --- (gdb) info functions tsrm* All functions matching regular expression "tsrm*": ... File TSRM.c: void tsrm_error_set(int, char *); pthread_mutex_t *tsrm_mutex_alloc(); void tsrm_mutex_free(pthread_mutex_t *); int tsrm_mutex_lock(pthread_mutex_t *); int tsrm_mutex_unlock(pthread_mutex_t *); void *tsrm_set_new_thread_begin_handler(void (*)()); void *tsrm_set_new_thread_end_handler(void (*)()); void tsrm_shutdown(); int tsrm_startup(int, int, int, char *); pthread_t tsrm_thread_id(); Non-debugging symbols: ef17823c _setsrq --- POSIX threads seem to override NSAPI, since they are used by default and checked before NSAPI. PHP fails to compile if configured --without-tsrm-pthreads TSRM.h: 48 /* Define THREAD_T and MUTEX_T */ .. 55 #elif defined(PTHREADS) 56 # define THREAD_T pthread_t 57 # define MUTEX_T pthread_mutex_t * 58 #elif defined(NSAPI) 59 # define THREAD_T SYS_THREAD 60 # define MUTEX_T CRITICAL ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=13174&edit=1