[nanomsg] Re: core dump from "Cannot assign requested address" error
- From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 9 Nov 2014 22:14:51 -0800
Hi,
I forgot to mention. The code which triggered it blew up when NN_IPV4ONLY was
set to zero.
To start with, whether to abort and core dump seems like an application
decision, not a library one. For example, if I use jnano in a Java servlet
container, I wouldn't want one mistake in one app to force-kill the entire
container, unless it's a real bad mistake, or some special flags are enabled
to do it on purpose for bug-fixing.
Also, it shouldn't core-dump just because of something minor like EAFNOTSUPP
or something similar.
Matthew.
On Sun, Nov 09, 2014 at 08:53:46PM -0800, Matthew Hall wrote:
> Hi Team,
>
> I captured this abort-triggered segfault during recent testing of my nanomsg
> based app stack. I saw it using the Perl bindings but the abort() in question
> seems to be perl-independent as far as I can see.
>
> To me it doesn't seem like a good thing to core-dump the application in this
> case unless there's a really good reason for it, and if there is, it would be
> nice if the error message explained more about why.
>
> Can anyone help me understand what happened in the output below?
>
> Thanks,
> Matthew.
>
> Cannot assign requested address [99] (src/transports/tcp/btcp.c:378)
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff76c1bb9 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0 0x00007ffff76c1bb9 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1 0x00007ffff76c4fc8 in __GI_abort () at abort.c:89
> #2 0x00007ffff5ac1309 in nn_err_abort () at src/utils/err.c:33
> #3 0x00007ffff5ade088 in nn_btcp_start_listening (self=0x62d2f0) at
> src/transports/tcp/btcp.c:378
> #4 0x00007ffff5add30d in nn_btcp_handler (self=0x62d2f0, src=-2, type=-2,
> srcptr=0x0) at src/transports/tcp/btcp.c:262
> #5 0x00007ffff5ab915a in nn_fsm_start (self=0x62d2f0) at src/aio/fsm.c:113
> #6 0x00007ffff5add234 in nn_btcp_create (hint=0x971ef0, epbase=0x971f50) at
> src/transports/tcp/btcp.c:153
> #7 0x00007ffff5ae185d in nn_tcp_bind (hint=0x971ef0, epbase=0x971f50) at
> src/transports/tcp/tcp.c:85
> #8 0x00007ffff5aafb45 in nn_ep_init (self=0x971ef0, src=1, sock=0x971950,
> eid=1, transport=0x7ffff5cef810 <nn_tcp_vfptr>, bind=1, addr=0x61d876
> "[192.168.1.77]:31337") at src/core/ep.c:70
> #9 0x00007ffff5ab6e19 in nn_sock_add_ep (self=0x971950,
> transport=0x7ffff5cef810 <nn_tcp_vfptr>, bind=1, addr=0x61d876
> "[192.168.1.77]:31337") at src/core/sock.c:479
> #10 0x00007ffff5ab1c1e in nn_global_create_ep (s=0, addr=0x61d876
> "[192.168.1.77]:31337", bind=1) at src/core/global.c:1112
> #11 0x00007ffff5ab19d6 in nn_bind (s=0, addr=0x61d870
> "tcp://[192.168.1.77]:31337") at src/core/global.c:611
> #12 0x00007ffff5cf278a in XS_NanoMsg__Raw_nn_bind (my_perl=<optimized out>,
> cv=<optimized out>) at Raw.c:500
> #13 0x00007ffff7b0a866 in Perl_pp_entersub () from /usr/lib/libperl.so.5.18
> #14 0x00007ffff7b02e86 in Perl_runops_standard () from
> /usr/lib/libperl.so.5.18
> #15 0x00007ffff7a9b844 in perl_run () from /usr/lib/libperl.so.5.18
> #16 0x0000000000400dd9 in main ()
> (gdb)
>
Other related posts:
