hello,
We are trying to get small text file from the internet using mrpeach net objects.
there is some few crash. gdb backtrace gives :
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff8cf81700 (LWP 31771)] 0x00007fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 225 x->x_addr = ntohl(*(long *)hp->h_addr); (gdb) watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 #1 0x00007ffff73a8f6e in start_thread (arg=0x7fff8cf81700) at pthread_create.c:311 #2 0x00007ffff6ecf9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(this is on ubuntu 13.10 linux 64 bit / pd 0.45 / mrpeach from svn, but osX gives the same kind of crash )
iemnet object are not more stable.
there are lot's of thread about this in the list. is there anything new, or something we can do to avoid crash?
or is there an other solution that would be cross platform (linux, osX, windows) and would allow a patch to download text file from a server?
thanks cheers Cyrille
On 2014-02-12 11:13, Cyrille Henry wrote:
hello,
We are trying to get small text file from the internet using mrpeach net objects.
there is some few crash. gdb backtrace gives :
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff8cf81700 (LWP 31771)] 0x00007fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 225 x->x_addr = ntohl(*(long *)hp->h_addr); (gdb) watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007fffeab9fa94 in tcpclient_child_connect (w=0x7fffea88d010) at tcpclient.c:225 #1 0x00007ffff73a8f6e in start_thread (arg=0x7fff8cf81700) at pthread_create.c:311 #2 0x00007ffff6ecf9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(this is on ubuntu 13.10 linux 64 bit / pd 0.45 / mrpeach from svn, but osX gives the same kind of crash )
iemnet object are not more stable.
there are lot's of thread about this in the list. is there anything new, or something we can do to avoid crash?
I don't recall any threads about this kind of crash. It looks like a 64-bit issue. If it really crashes at x->x_addr = ntohl(*(long *)hp->h_addr); then possibly the long type is too long or the h_addr field is not a long in 64-bit or h_addr is not properly initialized, so ntohl() looks in the wrong place and segfaults. I never get any such crashes on 32-bit systems, but so far I haven't tried it on 64-bit.
or is there an other solution that would be cross platform (linux, osX, windows) and would allow a patch to download text file from a server?
You could probably make a single object with pdlua or pyext that does just that.
Martin
thanks cheers Cyrille
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2014-02-12 11:51, Martin Peach wrote:
It looks like a 64-bit issue. If it really crashes at x->x_addr = ntohl(*(long *)hp->h_addr); then possibly the long type is too long or the h_addr field is not a long in 64-bit or h_addr is not properly initialized, so ntohl() looks in the wrong place and segfaults. I never get any such crashes on 32-bit systems, but so far I haven't tried it on 64-bit.
I just committed a change to tcpclient.c in svn that might fix it, changing long to uint32_t to make sure it accesses a 32-bit field.
Martin
hello Martin,
thanks a lot for the quick fix. It did not crash any more on my 64b linux computer. we will perform long term stability test.
thanks cheers cyrille
Le 12/02/2014 19:46, Martin Peach a écrit :
On 2014-02-12 11:51, Martin Peach wrote:
It looks like a 64-bit issue. If it really crashes at x->x_addr = ntohl(*(long *)hp->h_addr); then possibly the long type is too long or the h_addr field is not a long in 64-bit or h_addr is not properly initialized, so ntohl() looks in the wrong place and segfaults. I never get any such crashes on 32-bit systems, but so far I haven't tried it on 64-bit.
I just committed a change to tcpclient.c in svn that might fix it, changing long to uint32_t to make sure it accesses a 32-bit field.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list