[3dprinter-general] Bug#985473: Bug#985473: slic3r: symbol lookup error after gcode export

Gregor Riepl onitake at gmail.com
Wed Apr 7 23:57:06 BST 2021


> Hmmm, when I connect gdb to the process, I get an immediate
> 
> 0x00007f9480ca33ff in __GI___poll (fds=0x55943c327d50, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> 29	../sysdeps/unix/sysv/linux/poll.c: No such file or directory.

gdb automatically breaks on all signals, and this might be a SIGALRM or
some other non-aborting signal.

You can probably ignore it safely.

> boost::nowide::setenv(char const*, char const*, int)@plt
> 
> and sliced AK_Bed.stl
> 
> gdb did halt on the breakpoint, and got
> Thread 73 "perl" hit Breakpoint 1, 0x00007f948024f700 in boost::nowide::setenv(char const*, char const*, int)@plt ()
>    from /usr/lib/slic3r/auto/Slic3r/XS/XS.so

I suppose a "cont" will crash the program here, correct?

The @plt symbol is actually *not* the routine being called, but a stub
generated by the compiler that takes care of runtime linking. If the
dynamic linker can't find the symbol in any loaded library, it will crash.

I compiled a quick test program, linked it against
libboost_nowide.so.1.74.0 and it works as expected. The dynamic symbol
being called is the same as the one you reported:
_ZN5boost6nowide6setenvEPKcS2_i

This leads me to the conclusion that nothing is with boost_nowide per
se. Can you do a

ldd /usr/lib/slic3r/auto/Slic3r/XS/XS.so

and check if you see /usr/lib/x86_64-linux-gnu/libboost_nowide.so.1.74.0
somewhere in there?



More information about the 3dprinter-general mailing list