On 09/20/11 12:17, Damyan Ivanov wrote: > Hi, > > I have a Perl script that used IBPerl for connecting to Firebird. The > script is used for some mass data processing, and uses alarm() to > provide feedback (prints number of processed input lines). > > That same script used to work just fine until I upgraded the > libfbclient2 to 2.5.1.26349-0 (RC1, from the Debian package). > Downgrading the package to 2.5.0.26074-0 (2.5.0 final) makes the > segfault go away. > > It is perfectly possible that IBPerl is doing something bad, but since > the script works with an older fbclient, I thought there could be > a problem with the 2.5.1 RC1 version. The very same script works > flawlessly if I drop the alarm() calls. All the SIGALRM catching is > done via Perl signals, which are reliable, i.e. they are guaranteed > not to interrupt syscalls etc. > > Here is a backtrace and some poking at the variables: > > Thread 2 (Thread 0x7ffff539b700 (LWP 10073)): > #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86 > #1 0x00007ffff6aef238 in Firebird::SignalSafeSemaphore::enter > (this=0x7ffff7fe6128) at ../src/common/classes/semaphore.cpp:95 > #2 0x00007ffff6ab08b9 in (anonymous namespace)::shutdownThread () at > ../src/jrd/why.cpp:933 > #3 0x00007ffff6aacf86 in run (this=<synthetic pointer>) at > ../src/jrd/ThreadStart.cpp:128 > #4 (anonymous namespace)::threadStart (arg=0x7ffff7fe5b38) at > ../src/jrd/ThreadStart.cpp:139 > #5 0x00007ffff7741b40 in start_thread (arg=<optimized out>) at > pthread_create.c:304 > #6 0x00007ffff748c36d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #7 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7ffff7fd1700 (LWP 10070)): > #0 __memcpy_sse2 () at ../sysdeps/x86_64/multiarch/../memcpy.S:78 > #1 0x00007ffff6ad3287 in REM_fetch (user_status=0x1581890, > stmt_handle=<optimized out>, blr_length=<optimized out>, > blr=0x7ffff7fdbef8 "\370\276\375\367\377\177", msg_type=0, msg_length=6, > msg=0x7ffff7fdba78 "") at ../src/remote/interface.cpp:1905 > #2 0x00007ffff6ab50e9 in isc_dsql_fetch_m (user_status=<optimized out>, > stmt_handle=<optimized out>, blr_length=12, > blr=0x7ffff7fdba90 "\005\002\004", msg_type=0, msg_length=6, > msg=0x7ffff7fdba78 "") at ../src/jrd/why.cpp:3256 > #3 0x00007ffff6ab52d4 in isc_dsql_fetch (user_status=<optimized out>, > stmt_handle=0x1581888, dialect=3, sqlda=0x15f7ec0) > at ../src/jrd/why.cpp:3138 > #4 0x00007ffff6d6b70e in XS_IBPerl__Statement_IB_fetch (my_perl=<optimized > out>, cv=<optimized out>) at IBPerl.xs:1473 > #5 0x00000000004dea07 in Perl_pp_entersub (my_perl=0x89d010) at pp_hot.c:2888 > #6 0x00000000004aa486 in Perl_runops_debug (my_perl=0x89d010) at dump.c:2049 > #7 0x000000000044851e in S_run_body (oldscope=1, my_perl=0x89d010) at > perl.c:2308 > #8 perl_run (my_perl=0x89d010) at perl.c:2233 > #9 0x00000000004243f7 in main (argc=6, argv=0x7fffffffe128, > env=0x7fffffffe160) at perlmain.c:117 > (gdb) frame 1 > #1 0x00007ffff6ad3287 in REM_fetch (user_status=0x1581890, > stmt_handle=<optimized out>, blr_length=<optimized out>, > blr=0x7ffff7fdbef8 "\370\276\375\367\377\177", msg_type=0, msg_length=6, > msg=0x7ffff7fdba78 "") at ../src/remote/interface.cpp:1905 > 1905 memcpy(msg, message->msg_address, msg_length); > (gdb) p msg_length > $1 = 6 > (gdb) p msg > $2 = (UCHAR *) 0x7ffff7fdba78 "" > (gdb) p message > $3 = (RMessage *) 0x7ffff7fdbef8 > (gdb) p message->msg_address > $4 = (UCHAR *) 0x0 > > So it seems the msg_address member is 0 and memcpy rightfully throws > a segmentation fault. > > Does this ring any bells? Is there more information I could supply?
This does look like firebird bug. When isc_dsql_fetch() API call is used, user has no access to message internals. What is the best way to reproduce this bug? ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
