On 14/05/16 01:44 PM, Rohan Garg wrote: > I'd need to look at the beginning of the stacktraces to understand > what's going on, may be 20-30 frames from the beginning. You can do a > 'bactrace -20' to see the bottom 20 frames in gdb.
Sorry, of course, but I didn't know how to do that, and for some reason missed in it "help bt", Stupidly was trying to find bottom of stack by going "frame N" for various N, from "help stack" as opposed to "help bt" for more specific info on bt... arrrgh. 2.4.4 > #37416 0x00007ffff7deb3c1 in _dl_signal_error () from > /lib64/ld-linux-x86-64.so.2 > #37417 0x00007ffff7deb573 in _dl_signal_cerror () from > /lib64/ld-linux-x86-64.so.2 > #37418 0x00007ffff7de6303 in _dl_lookup_symbol_x () from > /lib64/ld-linux-x86-64.so.2 > #37419 0x00007ffff6715161 in do_sym () from /lib64/libc.so.6 > #37420 0x00007ffff6715543 in _dl_vsym () from /lib64/libc.so.6 > #37421 0x00007ffff6bb6198 in dlvsym_doit () from /lib64/libdl.so.2 > #37422 0x00007ffff7deb5f4 in _dl_catch_error () from > /lib64/ld-linux-x86-64.so.2 > #37423 0x00007ffff6bb6631 in _dlerror_run () from /lib64/libdl.so.2 > #37424 0x00007ffff6bb61ed in dlvsym () from /lib64/libdl.so.2 > #37425 0x00007ffff732cfd4 in initialize_libc_wrappers () at syscallsreal.c:277 > #37426 0x00007ffff72ea72a in dmtcp_prepare_wrappers () at dmtcpworker.cpp:145 > #37427 0x00007ffff7bd9bdf in malloc (size=72704) at mallocwrappers.cpp:40 > #37428 0x00007ffff62df180 in ?? () from /lib64/libstdc++.so.6 > #37429 0x00007ffff7deb74a in call_init.part () from > /lib64/ld-linux-x86-64.so.2 > #37430 0x00007ffff7deb85b in _dl_init () from /lib64/ld-linux-x86-64.so.2 > #37431 0x00007ffff7ddccba in _dl_start_user () from > /lib64/ld-linux-x86-64.so.2 > #37432 0x0000000000000002 in ?? () > #37433 0x00007fffffffde42 in ?? () > #37434 0x00007fffffffde54 in ?? () > #37435 0x0000000000000000 in ?? () 2.5rc1 > #44898 0x00007ffff7deb3c1 in _dl_signal_error () from > /lib64/ld-linux-x86-64.so.2 > #44899 0x00007ffff7deb573 in _dl_signal_cerror () from > /lib64/ld-linux-x86-64.so.2 > #44900 0x00007ffff7de6303 in _dl_lookup_symbol_x () from > /lib64/ld-linux-x86-64.so.2 > #44901 0x00007ffff6509161 in do_sym () from /lib64/libc.so.6 > #44902 0x00007ffff6509543 in _dl_vsym () from /lib64/libc.so.6 > #44903 0x00007ffff69aa198 in dlvsym_doit () from /lib64/libdl.so.2 > #44904 0x00007ffff7deb5f4 in _dl_catch_error () from > /lib64/ld-linux-x86-64.so.2 > #44905 0x00007ffff69aa631 in _dlerror_run () from /lib64/libdl.so.2 > #44906 0x00007ffff69aa1ed in dlvsym () from /lib64/libdl.so.2 > #44907 0x00007ffff71223ad in initialize_libc_wrappers () at syscallsreal.c:267 > #44908 dmtcp_prepare_wrappers () at syscallsreal.c:302 > #44909 0x00007ffff7bd9b8f in malloc (size=72704) at > alloc/mallocwrappers.cpp:40 > #44910 0x00007ffff60d3180 in ?? () from /lib64/libstdc++.so.6 > #44911 0x00007ffff7deb74a in call_init.part () from > /lib64/ld-linux-x86-64.so.2 > #44912 0x00007ffff7deb85b in _dl_init () from /lib64/ld-linux-x86-64.so.2 > #44913 0x00007ffff7ddccba in _dl_start_user () from > /lib64/ld-linux-x86-64.so.2 > #44914 0x0000000000000002 in ?? () > #44915 0x00007fffffffdbe0 in ?? () > #44916 0x00007fffffffdbf2 in ?? () 3.0 > #196441 0x00007ffff699f715 in _dlerror_run () from /lib64/libdl.so.2 > #196442 0x00007ffff699f148 in dlsym () from /lib64/libdl.so.2 > #196443 0x00007ffff7bd9da4 in free (ptr=0x63d010) at > alloc/mallocwrappers.cpp:74 > #196444 0x00007ffff699f715 in _dlerror_run () from /lib64/libdl.so.2 > #196445 0x00007ffff699f148 in dlsym () from /lib64/libdl.so.2 > #196446 0x00007ffff7bd9da4 in free (ptr=0x63d010) at > alloc/mallocwrappers.cpp:74 > #196447 0x00007ffff699f715 in _dlerror_run () from /lib64/libdl.so.2 > #196448 0x00007ffff699f1ed in dlvsym () from /lib64/libdl.so.2 > #196449 0x00007ffff711acd4 in initialize_libpthread_wrappers () at > syscallsreal.c:289 > #196450 dmtcp_prepare_wrappers () at syscallsreal.c:304 > #196451 0x00007ffff70d6f58 in dmtcp_initialize () at dmtcpworker.cpp:265 > #196452 0x00007ffff7bd9b8f in malloc (size=72704) at > alloc/mallocwrappers.cpp:40 > #196453 0x00007ffff60c8180 in ?? () from /lib64/libstdc++.so.6 > #196454 0x00007ffff7deb74a in call_init.part () from > /lib64/ld-linux-x86-64.so.2 > #196455 0x00007ffff7deb85b in _dl_init () from /lib64/ld-linux-x86-64.so.2 > #196456 0x00007ffff7ddccba in _dl_start_user () from > /lib64/ld-linux-x86-64.so.2 > #196457 0x0000000000000002 in ?? () > #196458 0x00007fffffffddaa in ?? () > #196459 0x00007fffffffddbc in ?? () > #196460 0x0000000000000000 in ?? () > It's hard to say what's the exact cause because I do use glibc-2.23 > (recently upgraded from 2.22) and haven't seen any issues so far. One would think it would have the same thing there. But it appears to be the combination of my setup and glibc2.22 that causes the problem. Could there be anything else about my setup (I provided kernel, gcc versions. What else might be different that would cause a mess up -- specifically with the memory allocation routines?) But it was with TWO separate systems, one 32 bit, one 64 bit, where it loops if using alloc plugin, and works otherwise. Suggests possible pebkac problem? HOWEVER, this would not be in building dmtcp. BECAUSE, the fedora 23 current repo version 2.4.2 has the SAME behavior (loops with alloc plugin, seems to work without). > Could you please confirm that the 3.0 zip you downloaded has the commits > from the following pull request: https://github.com/dmtcp/dmtcp/pull/372 ? Yes, it does. ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Dmtcp-forum mailing list Dmtcp-forum@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
