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?
Thanks for your time,
dam
------------------------------------------------------------------------------
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
