| Subject: | Segfault when receiving |
| Date: | Tue, 20 Mar 2012 20:42:26 +0100 |
| To: | bug-ZeroMQ [...] rt.cpan.org |
| From: | Florian Ragwitz <rafl [...] debian.org> |
On a perl 5.14.4 compiled with -DDEBUGGING and -Duseithreads, running
t/006_anyevent.t of ZeroMQ 0.20 compiled against version 2.1.11 of zmq,
results in a segfault.
$ ZMQ_TRACE=1 gdb --args perl -Mblib t/006_anyevent.t
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/rafl/.perl5141/bin/perl...done.
(gdb) r
Starting program: /home/rafl/.perl5141/bin/perl -Mblib t/006_anyevent.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ok 1 - use ZeroMQ::Raw;
ok 2 - use ZeroMQ::Constants;
# Using zmq_getsockopt + AE
# + Extracting ZMQ_FD
# + Creating AE::io for fd
# Waiting...
[New Thread 0x7ffff43cc700 (LWP 24657)]
[New Thread 0x7ffff3bcb700 (LWP 24658)]
# Sending data to server
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff3bcb700 (LWP 24658)]
0x0000000000531b36 in Perl_safesysfree (where=0x11c50d8) at util.c:256
256 DEBUG_m( PerlIO_printf(Perl_debug_log, "0x%"UVxf": (%05ld) free\n",PTR2UV(where),(long)PL_an++));
(gdb) thread apply all bt
Thread 3 (Thread 0x7ffff3bcb700 (LWP 24658)):
#0 0x0000000000531b36 in Perl_safesysfree (where=0x11c50d8) at util.c:256
#1 0x00007ffff57b7347 in PerlZMQ_free_string (data=0x11c50d8, hint=0x0) at xs/perl_zeromq.xs:190
#2 0x00007ffff55a2cb2 in zmq_msg_close (msg_=0x11e4220) at zmq.cpp:152
#3 zmq_msg_close (msg_=0x11e4220) at zmq.cpp:130
#4 0x00007ffff558ae75 in zmq::encoder_t::message_ready (this=0x11e41d8) at encoder.cpp:56
#5 0x00007ffff55a44d4 in get_data (offset_=<optimized out>, size_=<optimized out>, data_=<optimized out>, this=<optimized out>) at encoder.hpp:80
#6 zmq::zmq_engine_t::out_event (this=0x11e4120) at zmq_engine.cpp:165
#7 0x00007ffff558b5f2 in zmq::epoll_t::loop (this=0xb6e210) at epoll.cpp:157
#8 0x00007ffff559f206 in thread_routine (arg_=0xb6e280) at thread.cpp:75
#9 0x00007ffff70efb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#10 0x00007ffff6e3a90d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7ffff43cc700 (LWP 24657)):
#0 0x00007ffff6e3af63 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007ffff558b57f in zmq::epoll_t::loop (this=0xab5580) at epoll.cpp:142
#2 0x00007ffff559f206 in thread_routine (arg_=0xab55f0) at thread.cpp:75
#3 0x00007ffff70efb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#4 0x00007ffff6e3a90d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#5 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7ffff7fd2700 (LWP 24651)):
#0 0x00007ffff6e2fcc3 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007ffff5599f21 in zmq::signaler_t::wait (this=<optimized out>, timeout_=<optimized out>) at signaler.cpp:145
#2 0x00007ffff558dd62 in zmq::mailbox_t::recv (this=0xb6e5e0, cmd_=0x7fffffffcf20, timeout_=<optimized out>) at mailbox.cpp:74
#3 0x00007ffff559b2bd in zmq::socket_base_t::process_commands (this=0xb6e500, timeout_=<optimized out>, throttle_=false) at socket_base.cpp:713
#4 0x00007ffff559b526 in zmq::socket_base_t::recv (this=0xb6e500, msg_=0x7fffffffd130, flags_=0) at socket_base.cpp:618
#5 0x00007ffff57c88e3 in XS_ZeroMQ__Raw_zmq_recv (my_perl=0xa83010, cv=0x11111c0) at xs/perl_zeromq.xs:492
#6 0x00000000005a9a98 in Perl_pp_entersub (my_perl=0xa83010) at pp_hot.c:3046
#7 0x0000000000530bd8 in Perl_runops_debug (my_perl=0xa83010) at dump.c:2266
#8 0x00000000004537d4 in S_run_body (my_perl=0xa83010, oldscope=1) at perl.c:2350
#9 0x00000000004529ce in perl_run (my_perl=0xa83010) at perl.c:2268
#10 0x000000000041cd7d in main (argc=3, argv=0x7fffffffd788, env=0x7fffffffd7a8) at perlmain.c:120
(gdb) p PL_an
Cannot access memory at address 0x788
(gdb) p my_perl
$1 = (PerlInterpreter *) 0x0
In there you can see PerlZMQ_free_string attempting to free a chunk of
memory seemingly allocated for it by the perl interpreter in thread
1. However, I don't see how that could work without without that thread
#3 having a way to get to the interpreter used to allocate that memory
in the first place.
Depending on perl's configuration, that might either be a straight
lookup in an exported global, or getting user data attached to a thread
(cthread_data or pthread_getspecific depending on your system's thread
library).
In my configuration, the dTHX done in Perl_safesysfree will boil down to
a pthread_getspecific.
However, the thread #3, as created by zmq, not by perl's cloning
mechanism, will not have a perl interpreter as its user data, causing
freeing memory allocated in one thread on one perl interpreter fail when
done from another thread not closing over the same interpreter.
Changing the allocator used in the ZeroMQ module from perl's allocator
to libc's malloc, this particular issue goes away.
(not that the test would start passing, but now it doesn't shit itself
anymore when trying to free memory in different threads)