Hi,
I am running PHP 5.2.3 as a statically compiled module for a web server
(appWeb, which is an embbeded apache-like server).
My platform is a ppc processor, running Windriver Linux.
The problem I encounter is, that when printing many syslogs to the
system my web-server crashes.
I have backtraced the problem to a specific call to a 'free' system call
in the syslog.c extension:
PHP_FUNCTION(openlog)
{
char *ident;
long option, facility;
int ident_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sll", &ident,
&ident_len, &option, &facility) == FAILURE) {
return;
}
if (BG(syslog_device)) {
free(BG(syslog_device));
}
BG(syslog_device) = zend_strndup(ident, ident_len);
openlog(BG(syslog_device), option, facility); RETURN_TRUE; }
has anyone run into a same problem... or have any ideas as to how to
resolve this?
Here is a backtrace I extracted from the core:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 859800816 (LWP 15194)]
0x0fcdfa60 in free () from /lib/libc.so.6
(gdb) bt
#0 0x0fcdfa60 in free () from /lib/libc.so.6
#1 0x0f652630 in zif_openlog (ht=3, return_value=0x32838560,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0,
tsrm_ls=0x104aee30) at
/home/rachmel/work/php_for_appweb2/avaya_build_target/ext/standard/syslo
g.c:232
#2 0x0f7598b4 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ebad8, tsrm_ls=0x104aee30) at zend_vm_execute.h:200
#3 0x0f762628 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x333ebad8, tsrm_ls=0x104aee30) at zend_vm_execute.h:1681
#4 0x0f75918c in execute (op_array=0x10475f68, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#5 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ecbc8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#6 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ecbc8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#7 0x0f75918c in execute (op_array=0x10735178, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#8 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ecf18, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#9 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ecf18, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#10 0x0f75918c in execute (op_array=0x106d0188, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#11 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ed588, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#12 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ed588, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#13 0x0f75918c in execute (op_array=0x106c3950, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#14 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ed928, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#15 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ed928, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#16 0x0f75918c in execute (op_array=0x106d0a08, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#17 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333eea78, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#18 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333eea78, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#19 0x0f75918c in execute (op_array=0x103fafe0, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#20 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ef568, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#21 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ef568, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#22 0x0f75918c in execute (op_array=0x10363af0, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#23 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333ef8c8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#24 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333ef8c8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#25 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#26 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333efc18, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#27 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333efc18, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#28 0x0f75918c in execute (op_array=0x1041d818, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#29 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333eff78, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#30 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333eff78, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#31 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#32 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f0388, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#33 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f0388, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#34 0x0f75918c in execute (op_array=0x1041bb80, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#35 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f06e8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#36 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f06e8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#37 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#38 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f0e68, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#39 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f0e68, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#40 0x0f75918c in execute (op_array=0x10417de0, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#41 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f11c8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#42 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f11c8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#43 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#44 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f15e8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#45 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f15e8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#46 0x0f75918c in execute (op_array=0x104086a0, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#47 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f1948, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#48 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f1948, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#49 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#50 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f2058, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#51 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f2058, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#52 0x0f75918c in execute (op_array=0x10418890, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#53 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f23b8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#54 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f23b8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#55 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#56 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f2b58, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#57 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f2b58, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#58 0x0f75918c in execute (op_array=0x10417790, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#59 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f2eb8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#60 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f2eb8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#61 0x0f75918c in execute (op_array=0x10364608, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#62 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f39d8, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#63 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f39d8, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#64 0x0f75918c in execute (op_array=0x103d3780, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#65 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f4768, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#66 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f4768, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#67 0x0f75918c in execute (op_array=0x103d3628, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#68 0x0f759b54 in zend_do_fcall_common_helper_SPEC
(execute_data=0x333f5038, tsrm_ls=0x104aee30) at zend_vm_execute.h:234
#69 0x0f75acbc in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x333f5038, tsrm_ls=0x104aee30) at zend_vm_execute.h:322
#70 0x0f75918c in execute (op_array=0x10342090, tsrm_ls=0x104aee30) at
zend_vm_execute.h:92
#71 0x0f7227bc in zend_execute_scripts (type=8, tsrm_ls=0x104aee30,
retval=0x0, file_count=3)
at
/home/rachmel/work/php_for_appweb2/avaya_build_target/Zend/zend.c:1134
#72 0x0f6a0070 in php_execute_script (primary_file=0x333f74a0,
tsrm_ls=0x104aee30)
at
/home/rachmel/work/php_for_appweb2/avaya_build_target/main/main.c:1794
#73 0x0fa7ea94 in MaPhp5Handler::execScript (this=0x102d2050,
rq=0x1021a668) at php5Handler.cpp:434
#74 0x0fa7e820 in MaPhp5Handler::run (this=0x102d2050, rq=0x1021a668) at
php5Handler.cpp:399
#75 0x0ffaf324 in MaRequest::runHandlers (this=0x1021a668) at
request.cpp:2924
#76 0x0ffa9980 in MaRequest::processRequest (this=0x1021a668) at
request.cpp:761
#77 0x0ffa93b4 in MaRequest::readEvent (this=0x1021a668) at
request.cpp:626
#78 0x0ffa8fe0 in socketEventWrapper (data=0x1021a668, sock=0x1022ce98,
mask=2, isPool=1) at request.cpp:529
#79 0x0ffbd31c in MprSocket::ioProc (this=0x1022ce98, mask=2,
isMprPoolThread=1) at socket.cpp:1566
#80 0x0ed50a24 in MaSslSocket::ioProc (this=0x1022ce98, mask=2,
isPoolThread=1) at sslModule.cpp:507
#81 0x0ffbd1c4 in ioProcWrapper (data=0x1022ce98, mask=2,
isMprPoolThread=1) at socket.cpp:1545
#82 0x0ffb6168 in MprSelectHandler::selectProc (this=0x1021a048,
tp=0x10694c58) at select.cpp:1216
#83 0x0ffb6068 in selectProcWrapper (data=0x1021a048, tp=0x10694c58) at
select.cpp:1188
#84 0x0ffc008c in MprPoolThread::threadMain (this=0x10157b80) at
task.cpp:711
#85 0x0ffbfef0 in threadMainWrapper (arg=0x10157b80, tp=0x10157c20) at
task.cpp:670
#86 0x0ffc1f88 in MprThread::threadProc (this=0x10157c20) at
thread.cpp:318
#87 0x0ffc1eec in threadProcWrapper (data=0x10157c20) at thread.cpp:304
#88 0x0ff2ff48 in start_thread () from /lib/libpthread.so.0
#89 0x0fd42abc in clone () from /lib/libc.so.6
Previous frame inner to this frame (corrupt stack?)
Thanks in advance, Nir.
Here is a backtrace I extracted from the core:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 859800816 (LWP 15194)]
0x0fcdfa60 in free () from /lib/libc.so.6
(gdb) bt
#0 0x0fcdfa60 in free () from /lib/libc.so.6
#1 0x0f652630 in zif_openlog (ht=3, return_value=0x32838560,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0,
tsrm_ls=0x104aee30) at
It might also help if you print basic_globals contents:
(gdb) p basic_globals
--
Wbr,
Antony Dovgal
Do you mean printing the 'tsrm_ls'?
There is no 'basic_globals' symbol in the context of any of the frames I
tried.
Thanks, Nir.
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Sunday, November 25, 2007 4:23 PM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
Here is a backtrace I extracted from the core:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 859800816 (LWP 15194)] 0x0fcdfa60 in free () from
/lib/libc.so.6
(gdb) bt
#0 0x0fcdfa60 in free () from /lib/libc.so.6
#1 0x0f652630 in zif_openlog (ht=3, return_value=0x32838560,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0,
tsrm_ls=0x104aee30) at
It might also help if you print basic_globals contents:
(gdb) p basic_globals
--
Wbr,
Antony Dovgal
Do you mean printing the 'tsrm_ls'?
There is no 'basic_globals' symbol in the context of any of the frames I
tried.
Oh, so this is multithreaded version..
That makes it even more complicated.
--
Wbr,
Antony Dovgal
If it helps, I am attaching the relevant tsrm_ls (according to the
globals_id in the relevant frame):
(gdb) print (( (php_basic_globals) (((void**)tsrm_ls))[17]))
$5 = {
user_shutdown_function_names = 0x0,
putenv_ht = {
nTableSize = 8,
nTableMask = 7,
nNumOfElements = 0,
nNextFreeElement = 0,
pInternalPointer = 0x0,
pListHead = 0x0,
pListTail = 0x0,
arBuckets = 0x105d6c80,
pDestructor = 0xf5e9384 <php_putenv_destructor>,
persistent = 0 '\0',
nApplyCount = 0 '\0',
bApplyProtection = 1 '\001',
inconsistent = 0
},
strtok_zval = 0x1071b7d0,
strtok_string = 0x1071b750 "DEVICE_NOT_FRESH\t\n",
locale_string = 0x0,
strtok_last = 0x0,
strtok_table = '\0' <repeats 255 times>,
strtok_len = 18,
str_ebuf = 'Z' <repeats 40 times>,
array_walk_func_name = 0x0,
user_compare_func_name = 0x0,
user_compare_fci_cache = {
initialized = 0 '\0',
function_handler = 0x0,
calling_scope = 0x0,
object_pp = 0x0
},
user_tick_functions = 0x0,
active_ini_file_section = 0x1048d840,
sm_protected_env_vars = {
nTableSize = 8,
nTableMask = 7,
nNumOfElements = 1,
nNextFreeElement = 0,
pInternalPointer = 0x1062bee8,
pListHead = 0x1062bee8,
pListTail = 0x1062bee8,
arBuckets = 0x10613a30,
pDestructor = 0,
persistent = 1 '\001',
nApplyCount = 0 '\0',
bApplyProtection = 1 '\001',
inconsistent = 0
},
sm_allowed_env_vars = 0x1062bf20 "PHP_",
page_uid = -1,
page_gid = -1,
page_inode = -1,
page_mtime = -1,
CurrentStatFile = 0x106bcfa0
"/usr/local/web/443/lba/admin-webapp/language/langNames.php",
CurrentLStatFile = 0x0,
ssb = {
sb = {
st_dev = 11,
__pad1 = 0,
st_ino = 33566,
st_mode = 33279,
st_nlink = 1,
st_uid = 0,
st_gid = 0,
st_rdev = 0,
__pad2 = 0,
st_size = 127,
st_blksize = 4096,
st_blocks = 8,
st_atim = {
tv_sec = 1195994953,
tv_nsec = 0
},
st_mtim = {
tv_sec = 1151584283,
tv_nsec = 0
},
st_ctim = {
tv_sec = 1195988138,
tv_nsec = 0
},
__unused4 = 0,
__unused5 = 0
}
},
lssb = {
sb = {
st_dev = 5221693480379613281,
__pad1 = 0,
st_ino = 1930623196,
st_mode = 905716976,
st_nlink = 262134680,
st_uid = 247,
st_gid = 0,
st_rdev = 44,
__pad2 = 7513,
st_size = 1515870810,
st_blksize = 1515870810,
st_blocks = 1515870810,
st_atim = {
tv_sec = 1515870810,
tv_nsec = 1515870810
},
st_mtim = {
tv_sec = 1515870810,
tv_nsec = 1515870810
},
st_ctim = {
tv_sec = 1515870810,
tv_nsec = 1515870810
},
__unused4 = 1515870810,
__unused5 = 1515870810
}
},
state = {1515870810, 3424178695, 1215769902, 97, 2976, 1930623196,
905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215769934, 97, 3072,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215770094, 97, 3168,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215769614, 97, 3264,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215769774, 97, 3360,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215769806, 97, 3456,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215763310, 97, 3552,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215763342, 97, 3648,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695, 1215762990, 97, 3744,
1930623196, 905716976, 262134680, 247, 0, 0, 44, 492393095,
1515870810 <repeats 12 times>, 3424178695...},
next = 0x0,
left = -1,
rand_seed = 804607834,
rand_is_seeded = 1 '\001',
mt_rand_is_seeded = 0 '\0',
syslog_started = 1,
syslog_device = 0x5a5a5a5a <Address 0x5a5a5a5a out of bounds>,
incomplete_class = 0x100ac060,
url_adapt_state = {
state = STATE_NORMAL,
tag = 0x0,
attr = 0x0,
val = 0x0,
delim = 0 '\0',
p = 0x0,
l = 0,
ml = 0,
attr_done = 0
},
url_adapt_state_ex = {
tag = {
c = 0x0,
len = 0,
a = 0
},
arg = {
c = 0x0,
len = 0,
a = 0
},
val = {
c = 0x0,
len = 0,
a = 0
},
buf = {
c = 0x0,
len = 0,
a = 0
},
result = {
c = 0x0,
len = 0,
a = 0
},
form_app = {
c = 0x0,
len = 0,
a = 0
},
url_app = {
c = 0x0,
len = 0,
a = 0
},
active = 0,
lookup_data = 0x0,
state = 0,
tags = 0x1062bf30
},
mmap_file = 0x1d595287,
mmap_len = 1515870810,
user_filter_map = 0x0,
mblen_state = {
__count = 0,
__value = {
__wch = 0,
__wchb = "\000\000\000"
}
},
umask = -1
}
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Sunday, November 25, 2007 4:37 PM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
Do you mean printing the 'tsrm_ls'?
There is no 'basic_globals' symbol in the context of any of the frames
I tried.
Oh, so this is multithreaded version..
That makes it even more complicated.
--
Wbr,
Antony Dovgal
If it helps, I am attaching the relevant tsrm_ls (according to the
globals_id in the relevant frame):
syslog_started = 1,
syslog_device = 0x5a5a5a5a <Address 0x5a5a5a5a out of bounds>,
So it's somehow got freed.
Try setting breakpoint to zm_shutdown_syslog() function to see if it was called before.
It should be called on shutdown only, but that's the only case when BG(syslog_device) is freed and not NULLed.
--
Wbr,
Antony Dovgal
Hi,
I tried your advice, and put a breakpoint at the shutdown function.
However it never reaches it! (not normally, and not before the SEGV is
sent).
In case I didn't write it in the previous threads, I am running the PHP
scripts from my web-server (appWeb, which is apache like for embedded
systems). PHP is compiled as a static module into it, so maybe the
shutdown procedure is never called since the PHP is "never shut down"?
I would appreciate any advice / ideas you might have,
Thanks in advance, Nir.
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Tuesday, November 27, 2007 8:40 AM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
If it helps, I am attaching the relevant tsrm_ls (according to the
globals_id in the relevant frame):
syslog_started = 1,
syslog_device = 0x5a5a5a5a <Address 0x5a5a5a5a out of bounds>,
So it's somehow got freed.
Try setting breakpoint to zm_shutdown_syslog() function to see if it was
called before.
It should be called on shutdown only, but that's the only case when
BG(syslog_device) is freed and not NULLed.
--
Wbr,
Antony Dovgal
Hi,
I have been doing some code-reading. Why is the RSHUTDOWN function for
syslog ext called only when run under win32?
Shouldn't the cleanup happen on linux as well?
Another question is for the use of zend_strndup instead of one of the
non-persistent memory allocation functions (i.e. estrndup() ) ?
There is no use for this variable after the request dies (as far as I
understand).
However, so far, I can't seem to understand who/what corrupts my memory.
What do you think about extending the RINIT function instead of:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT("define_syslog_variables")) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
}
return SUCCESS;
}
To be:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT("define_syslog_variables")) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
BG(syslog_device)=NULL; /* This is the addition */
}
return SUCCESS;
}
Thanks in advance, Nir.
-----Original Message-----
From: Rachmel, Nir (Nir) [mailto:rachmel@avaya.com]
Sent: Sunday, December 02, 2007 11:31 AM
To: Antony Dovgal
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
Hi,
I tried your advice, and put a breakpoint at the shutdown function.
However it never reaches it! (not normally, and not before the SEGV is
sent).
In case I didn't write it in the previous threads, I am running the PHP
scripts from my web-server (appWeb, which is apache like for embedded
systems). PHP is compiled as a static module into it, so maybe the
shutdown procedure is never called since the PHP is "never shut down"?
I would appreciate any advice / ideas you might have,
Thanks in advance, Nir.
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Tuesday, November 27, 2007 8:40 AM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
If it helps, I am attaching the relevant tsrm_ls (according to the
globals_id in the relevant frame):
syslog_started = 1,
syslog_device = 0x5a5a5a5a <Address 0x5a5a5a5a out of bounds>,
So it's somehow got freed.
Try setting breakpoint to zm_shutdown_syslog() function to see if it was
called before.
It should be called on shutdown only, but that's the only case when
BG(syslog_device) is freed and not NULLed.
--
Wbr,
Antony Dovgal
--
To unsubscribe,
visit: http://www.php.net/unsub.php
Hi,
I have been doing some code-reading. Why is the RSHUTDOWN function for
syslog ext called only when run under win32?
Shouldn't the cleanup happen on linux as well?
man closelog says it's not required.
DESCRIPTION
closelog() closes the descriptor being used to write to the system logger. The use of closelog() is optional.
Another question is for the use of zend_strndup instead of one of the
non-persistent memory allocation functions (i.e. estrndup() ) ?
There is no use for this variable after the request dies (as far as I
understand).
Right, if you use estrndup(), the memory is freed at the end of request,
while zend_strndup() bypasses Zend memory manager using malloc() directly.
However, so far, I can't seem to understand who/what corrupts my memory.
Me neither :/
What do you think about extending the RINIT function instead of:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT("define_syslog_variables")) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
BG(syslog_device)=NULL; /* This is the addition */
I think this would just create a memleak.
BG(syslog_device) is checked for NULL and freed in openlog() and MSHUTDOWN.
--
Wbr,
Antony Dovgal
Hi,
Are there any tools you can recommend me for debugging my error?
Standard gdb debugging doesn't seem to help, and using valgrind in a
real-time webserver environment simply doesn't work on my device (or on
anyone's device I guess.. :) ).
Thanks, Nir.
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Monday, December 03, 2007 5:41 PM
To: Rachmel, Nir (Nir)
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] FW: [PHP] PHP 5.2.3 segfault with syslog standard
extension
Hi,
I have been doing some code-reading. Why is the RSHUTDOWN function for
syslog ext called only when run under win32?
Shouldn't the cleanup happen on linux as well?
man closelog says it's not required.
DESCRIPTION
closelog() closes the descriptor being used to write to the
system logger. The use of closelog() is optional.
Another question is for the use of zend_strndup instead of one of the
non-persistent memory allocation functions (i.e. estrndup() ) ?
There is no use for this variable after the request dies (as far as I
understand).
Right, if you use estrndup(), the memory is freed at the end of request,
while zend_strndup() bypasses Zend memory manager using malloc()
directly.
However, so far, I can't seem to understand who/what corrupts my
memory.
Me neither :/
What do you think about extending the RINIT function instead of:
PHP_RINIT_FUNCTION(syslog)
{
if (INI_INT("define_syslog_variables")) {
start_syslog(TSRMLS_C);
} else {
BG(syslog_started)=0;
BG(syslog_device)=NULL; /* This is the addition */
I think this would just create a memleak.
BG(syslog_device) is checked for NULL and freed in openlog() and
MSHUTDOWN.
--
Wbr,
Antony Dovgal
Hi,
Are there any tools you can recommend me for debugging my error?
Standard gdb debugging doesn't seem to help, and using valgrind in a
real-time webserver environment simply doesn't work on my device (or on
anyone's device I guess.. :) ).
Well, these are two the most useful tools I know of.
Tracing code flow with GDB and memory errors with valgrind usually helps to locate any problem.
--
Wbr,
Antony Dovgal