Re: [MonetDB-users] segfault with monetdb_sql().

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 : push %rbp 0x00002aaaac66c389 : mov %rsp,%rbp 0x00002aaaac66c38c : sub $0x20,%rsp

Function prelude is just above.

0x00002aaaac66c390 : mov %rdi,-0x18(%rbp)

Stores the argument of the function into the stack. Here, a pointer to the string "time".

0x00002aaaac66c394 : mov 0x26d1d5(%rip),%rax # 0x2aaaac8d9570 0x00002aaaac66c39b : mov (%rax),%eax 0x00002aaaac66c39d : test %eax,%eax 0x00002aaaac66c39f : je 0x2aaaac66c3f7

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

0x00002aaaac66c3a1 : mov 0x26d288(%rip),%rax # 0x2aaaac8d9630 0x00002aaaac66c3a8 : mov (%rax),%eax 0x00002aaaac66c3aa : and $0x400,%eax 0x00002aaaac66c3af : test %eax,%eax 0x00002aaaac66c3b1 : je 0x2aaaac66c3eb 0x00002aaaac66c3b3 : mov 0x26d28e(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3ba : mov (%rax),%rdi 0x00002aaaac66c3bd : mov 0x26d17c(%rip),%rcx # 0x2aaaac8d9540 0x00002aaaac66c3c4 : lea 0x6202d(%rip),%rdx # 0x2aaaac6ce3f8 0x00002aaaac66c3cb : lea 0x61fd5(%rip),%rsi # 0x2aaaac6ce3a7 0x00002aaaac66c3d2 : mov $0x0,%eax 0x00002aaaac66c3d7 : callq 0x2aaaac662438 0x00002aaaac66c3dc : mov 0x26d265(%rip),%rax # 0x2aaaac8d9648 0x00002aaaac66c3e3 : mov (%rax),%rdi 0x00002aaaac66c3e6 : callq 0x2aaaac662038 0x00002aaaac66c3eb : mov 0x26d14e(%rip),%rdi # 0x2aaaac8d9540 0x00002aaaac66c3f2 : callq 0x2aaaac662518

End of the mal_set_lock macro. And the two following lines are the beginning of the for() loop on i.

0x00002aaaac66c3f7 : movl $0x0,-0x4(%rbp) 0x00002aaaac66c3fe : jmpq 0x2aaaac66c4ba

After this line above, execution goes to but comes back very quickly to the line below.

0x00002aaaac66c403 : mov -0x4(%rbp),%eax 0x00002aaaac66c406 : mov 0x26d193(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c40d : cltq 0x00002aaaac66c40f : mov (%rdx,%rax,8),%rax 0x00002aaaac66c413 : test %rax,%rax 0x00002aaaac66c416 : je 0x2aaaac66c4b6

Above is the expression 'box[i] != NULL'. As execution continues to the lines below, it seems that box[i] is indeed not NULL.

0x00002aaaac66c41c : mov -0x4(%rbp),%eax 0x00002aaaac66c41f : mov 0x26d17a(%rip),%rdx # 0x2aaaac8d95a0 0x00002aaaac66c426 : cltq 0x00002aaaac66c428 : mov (%rdx,%rax,8),%rax 0x00002aaaac66c42c : 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 : mov -0x18(%rbp),%rdi 0x00002aaaac66c434 : callq 0x2aaaac662b48

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/