Segmentation fault with latest 1.1 revision
Guus Sliepen
guus at tinc-vpn.org
Tue Jun 26 14:21:23 CEST 2012
On Tue, Jun 26, 2012 at 01:38:20PM +0200, Julien Muchembled wrote:
> I am trying 1.1 branch and I experience a segmentation fault upon ALRM signal.
> This looks like a race condition.
It should not be a race condition, since the signals are handled by the main
event loop, not in a special signal context. So it is something more serious...
> I have my tincd daemon instantiated manually in if-up.d/jmuchemb (without IF_TINC_NET) and when if-up.d/tinc runs, it sends a ALRM signal that makes tincd crash.
>
> It fails here:
>
> Core was generated by `tincd -D -n jmuchemb -d -o ConnectTo srv -o srv.Address 81.x.y.z -o Connect'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x000000000040a685 in retry () at net.c:349
> 349 if(c->outgoing && !c->node) {
> (gdb) p c
> $1 = (connection_t *) 0x0
Thanks for the backtrace!
> > write(2, "Got Alarm clock signal\n", 23) = 23
> > write(2, "Could not set up a meta connecti"..., 42) = 42
> > write(2, "Trying to re-establish outgoing "..., 56) = 56
> > epoll_ctl(14, EPOLL_CTL_DEL, 22, {EPOLLIN, {u32=22, u64=22}}) = 0
> > close(22) = 0
> > --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>
> It's easily reproducible for me so I can send more information if you want, including core dump, binaries (Debian) and strace log.
Ok, I see the problem already, retry() calls do_outgoing_connection(), which
can call connection_del(), which means "node = node->next" in retry() will give
wrong results. Expect a fix soon.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120626/03be9eaa/attachment.pgp>
More information about the tinc
mailing list