Guillaume Yziquel a écrit :
Martin Kersten a écrit :
Guillaume Yziquel wrote:
Martin Kersten a écrit :
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5
The segfault happens in this line of the function findBox. And more specifically when evaluating box[i]->name.
89 if (box[i] != NULL && idcmp(name, box[i]->name) == 0) {
The disassembled code for function findBox (amd64, Linux) is:
Dump of assembler code for function findBox: 0x00002aaaac66c388 <findBox+0>: push %rbp 0x00002aaaac66c389 <findBox+1>: mov %rsp,%rbp 0x00002aaaac66c38c <findBox+4>: sub $0x20,%rsp
Function prelude is just above.
0x00002aaaac66c390 <findBox+8>: mov %rdi,-0x18(%rbp)
Stores the argument of the function into the stack. Here, a pointer to the string "time".
0x00002aaaac66c394 <findBox+12>: mov 0x26d1d5(%rip),%rax # 0x2aaaac8d9570 0x00002aaaac66c39b <findBox+19>: mov (%rax),%eax 0x00002aaaac66c39d <findBox+21>: test %eax,%eax 0x00002aaaac66c39f <findBox+23>: je 0x2aaaac66c3f7 <findBox+111>
This is a test on GDKprotected, and execution goes from here into the macro mal_set_lock. Doesn't seem to be a big deal. After the macro, execution goes to <findBox+111>
0x00002aaaac66c3a1 <findBox+25>: mov 0x26d288(%rip),%rax # 0x2aaaac8d9630 0x00002aaaac66c3a8 <findBox+32>: mov (%rax),%eax 0x00002aaaac66c3aa <findBox+34>: and $0x400,%eax 0x00002aaaac66c3af <findBox+39>: test %eax,%eax 0x00002aaaac66c3b1 <findBox+41>: je 0x2aaaac66c3eb <findBox+99> 0x00002aaaac66c3b3 <findBox+43>: mov 0x26d28e(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3ba <findBox+50>: mov (%rax),%rdi 0x00002aaaac66c3bd <findBox+53>: mov 0x26d17c(%rip),%rcx # 0x2aaaac8d9540 0x00002aaaac66c3c4 <findBox+60>: lea 0x6202d(%rip),%rdx # 0x2aaaac6ce3f8 0x00002aaaac66c3cb <findBox+67>: lea 0x61fd5(%rip),%rsi # 0x2aaaac6ce3a7 0x00002aaaac66c3d2 <findBox+74>: mov $0x0,%eax 0x00002aaaac66c3d7 <findBox+79>: callq 0x2aaaac662438 <fprintf@plt> 0x00002aaaac66c3dc <findBox+84>: mov 0x26d265(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3e3 <findBox+91>: mov (%rax),%rdi 0x00002aaaac66c3e6 <findBox+94>: callq 0x2aaaac662038 <fflush@plt> 0x00002aaaac66c3eb <findBox+99>: mov 0x26d14e(%rip),%rdi # 0x2aaaac8d9540 0x00002aaaac66c3f2 <findBox+106>: callq 0x2aaaac662518 <pthread_mutex_lock@plt>
End of the mal_set_lock macro. And the two following lines are the beginning of the for() loop on i.
0x00002aaaac66c3f7 <findBox+111>: movl $0x0,-0x4(%rbp) 0x00002aaaac66c3fe <findBox+118>: jmpq 0x2aaaac66c4ba <findBox+306>
After this line above, execution goes to <findBox+306> but comes back very quickly to the line below.
0x00002aaaac66c403 <findBox+123>: mov -0x4(%rbp),%eax 0x00002aaaac66c406 <findBox+126>: mov 0x26d193(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c40d <findBox+133>: cltq 0x00002aaaac66c40f <findBox+135>: mov (%rdx,%rax,8),%rax 0x00002aaaac66c413 <findBox+139>: test %rax,%rax 0x00002aaaac66c416 <findBox+142>: je 0x2aaaac66c4b6 <findBox+302>
Above is the expression 'box[i] != NULL'. As execution continues to the lines below, it seems that box[i] is indeed not NULL.
0x00002aaaac66c41c <findBox+148>: mov -0x4(%rbp),%eax 0x00002aaaac66c41f <findBox+151>: mov 0x26d17a(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c426 <findBox+158>: cltq 0x00002aaaac66c428 <findBox+160>: mov (%rdx,%rax,8),%rax 0x00002aaaac66c42c <findBox+164>: mov 0x28(%rax),%rsi
Segmentation fault happens at the line just above. We were just preparing the argument 'box[i]->name' for the idcmp function. (This segfault has been observed with ddd. I could not figure out how to get gdb to step into machine code instruction from its command line.)
0x00002aaaac66c430 <findBox+168>: mov -0x18(%rbp),%rdi 0x00002aaaac66c434 <findBox+172>: callq 0x2aaaac662b48 <idcmp@plt>
So:
i suspect box[i] is not properly initialized to 0
Well, it seems that it is properly initialised to 0.
and 'print box[i]' misleadingly gave a '(Box) 0x0'... (that I still do not understand). So what does it mean, if box[i] is not properly initialised to 0? All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/