[zeromq-dev] OpenPGM & segfault - assertion failed

Martin Sustrik sustrik at 250bpm.com
Thu May 6 11:49:03 CEST 2010


Steven McCoy wrote:

> That just leaves a lot of invalid reads in zmq::pgm_receiver_t

Great. Let's have a look at the first non-OpenPGM invalid read:

==13537== Invalid read of size 4
==13537==    at 0x406052A: zmq::pgm_socket_t::receive(void**, pgm_tsi_t 
const**) (pgm_socket.cpp:502)
==13537==    by 0x405EC28: zmq::pgm_receiver_t::in_event() 
(pgm_receiver.cpp:137)
...

The block it is trying to access was originally allocated here, but 
freed afterwards:

==13537==  Address 0x45867b4 is 108 bytes inside a block of size 1,628 
free'd
==13537==    at 0x4022B8A: free (vg_replace_malloc.c:323)
==13537==    by 0x4387425: g_free (in /usr/lib/libglib-2.0.so.0.1600.6)
==13537==    by 0x4080D46: _pgm_rxw_remove_trail (skbuff.h:112)
==13537==    by 0x4081AFF: _pgm_rxw_append (rxwi.c:1088)
==13537==    by 0x4083442: pgm_rxw_add (rxwi.c:423)
==13537==    by 0x40914EF: pgm_on_data (receiver.c:2078)
==13537==    by 0x409383E: pgm_recvmsgv (recv.c:476)
==13537==    by 0x406059B: zmq::pgm_socket_t::receive(void**, pgm_tsi_t 
const**) (pgm_socket.cpp:459)
==13537==    by 0x405EC28: zmq::pgm_receiver_t::in_event() 
(pgm_receiver.cpp:137)
==13537==    by 0x405995D: zmq::epoll_t::loop() (epoll.cpp:197)
==13537==    by 0x4059A4C: zmq::epoll_t::worker_routine(void*) 
(epoll.cpp:210)
==13537==    by 0x406F2A6: zmq::thread_t::thread_routine(void*) 
(thread.cpp:99)


Here's the code that fails:


     const PGMIOStatus status = pgm_recvmsgv (transport, pgm_msgv,
         pgm_msgv_len, MSG_DONTWAIT, &nbytes_rec, &pgm_error);

     ... checking statuses here ...

     struct pgm_sk_buff_t* skb =
         pgm_msgv [pgm_msgv_processed].msgv_skb [0];

     // Take pointers from pgm_msgv_t structure.
     *raw_data_ = skb->data; // <============== invalid read
     raw_data_len = skb->len;

Hm. Strange.

In any case this code was changed in the trunk so it would be 
interesting to test the trunk version and see whether the problem still 
happens.

Martin



More information about the zeromq-dev mailing list