Package segfaults, either installed from binary, or compiled from ports...

Wolferz · 01-31-2017, 12:42 AM

Thanks Gents

I will have to look at this with more time.

I must use this app ( cgx binary from calculix package ) to build a finite elements model of a Diesel Engine injector assembly, to test for thermal load. In my company ( the one i work for ) we have been running with some problems with the previous model, so i completely redesigned the thing. I will have to use it in Linux, before being able to run it seamlessly in Freebsd.

Strangely though, ccx binary, ( the solver that actually does the number crunching ) runs flawlessly in freebsd...

Thanks anyway

jggimi · 01-31-2017, 05:30 AM

Quote:

Originally Posted by pan64

but actually if you are right...

That's a 64-bit address which I'm certain is invalid. In decimal, it's 140,070,766,272,208. That's more than 127 terabytes.

Wolferz · 01-31-2017, 07:10 AM

Quote:

Originally Posted by jggimi

That's a 64-bit address which I'm certain is invalid. In decimal, it's 140,070,766,272,208. That's more than 127 terabytes.

Like i said... i only wish i had the time to delve into the code, and find out just how the address pointer gets malformed, googled for getcontext() libc bugs in Freebsd, and found a potentially useful link...

https://groups.google.com/forum/m/#!...le/kMxuEzsPrCM

but as of NOW, i need to have this app ( cgx ) alive and kicking... in need to complete the digital mockup of the injector model so as to make a sensibility analysis od my design parameters, to assess expected reliability under service loads; in short words, get the best "bang for the buck".

As soon as a find a way to get it to work in *BSD, instead of posting from inside a VM, i will be using it natively in my mobo.

jggimi · 01-31-2017, 07:52 AM

Here's a hint: 3 minutes with the gdb(1) man page, or 10 seconds right here.

Code:

$ gdb /path/to/program /path/to/core/file

gdb() will produce a bunch of heading messages, then give you a (gdb) prompt, where you can ask for a backtrace.

Code:

(gdb) bt

From the backtrace, perhaps even without debugging symbols, you should be able to discern which module was the last to be called before the failure. If not, you can rebuild your program with symbols and try again.

Right now, you do not know the cause of the failure. It could be the application. It could be a supporting library. But until you are able to determine the root cause, all else is a blend of what appears to be to some unsubstantiated wild guesses and magical thinking.

Wolferz · 01-31-2017, 08:13 AM

Quote:

Originally Posted by jggimi

Here's a hint: 3 minutes with the gdb(1) man page, or 10 seconds right here.

Code:

$ gdb /path/to/program /path/to/core/file

gdb() will produce a bunch of heading messages, then give you a (gdb) prompt, where you can ask for a backtrace.

Code:

(gdb) bt

From the backtrace, perhaps even without debugging symbols, you should be able to discern which module was the last to be called before the failure. If not, you can rebuild your program with symbols and try again.

Right now, you do not know the cause of the failure. It could be the application. It could be a supporting library. But until you are able to determine the root cause, all else is a blend of what appears to be to some unsubstantiated wild guesses and magical thinking.

last module called was __cxxabiv1::__si_class_type_info in libcxxrt.so

Code:

Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000804870268 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1
[New Thread 805c18000 (LWP 101269/<unknown>)]
(gdb) bt
#0  0x0000000804870268 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1
#1  0x0000000802406975 in ?? () from /usr/local/lib/gcc49/libstdc++.so.6
#2  0x00000008026bc3c0 in ?? () from /usr/local/lib/gcc49/libstdc++.so.6
#3  0x00007fffffffde20 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb)

in the mean time, i also checked this...

Code:

root@izar:~ # readelf -d /usr/local/bin/cgx | grep NEEDED
 0x0000000000000001 NEEDED               Shared library: [libGL.so.1]
 0x0000000000000001 NEEDED               Shared library: [libGLU.so.1]
 0x0000000000000001 NEEDED               Shared library: [libX11.so.6]
 0x0000000000000001 NEEDED               Shared library: [libXi.so.6]
 0x0000000000000001 NEEDED               Shared library: [libXmu.so.6]
 0x0000000000000001 NEEDED               Shared library: [libXext.so.6]
 0x0000000000000001 NEEDED               Shared library: [libXt.so.6]
 0x0000000000000001 NEEDED               Shared library: [libSM.so.6]
 0x0000000000000001 NEEDED               Shared library: [libICE.so.6]
 0x0000000000000001 NEEDED               Shared library: [libthr.so.3]
 0x0000000000000001 NEEDED               Shared library: [librt.so.1]
 0x0000000000000001 NEEDED               Shared library: [libstdc++.so.6]
 0x0000000000000001 NEEDED               Shared library: [libm.so.5]
 0x0000000000000001 NEEDED               Shared library: [libgcc_s.so.1]
 0x0000000000000001 NEEDED               Shared library: [libc.so.7]
root@izar:~ #

...so, right now i know that libcxxrt.so calls something in libstdc++.so.6 thac causes the program to segfault.

Thanks 4 your help, i feel i'm making some progress here...

Wolferz · 01-31-2017, 08:20 AM

....talk about a can of worms... :/

https://forums.freebsd.org/threads/56542/

:/ :/

jggimi · 01-31-2017, 08:20 AM

Quote:

Originally Posted by Wolferz

...so, right now i know that libcxxrt.so calls something in libstdc++.so.6 ...

I believe you are misreading the output. The top of the trace is the most recent entry.

You will want to step through the application to discern what *it* is calling, and with what variable values, to cause the segfault. Helpfully, gdb() can step through an application (if built with debugging symbols) by function, by line-of-code, and even by compiled machine instruction. Line-of-code will be the most useful in such an exercise.

Wolferz · 01-31-2017, 08:28 AM

Quote:

Originally Posted by jggimi

I believe you are misreading the output. The top of the trace is the most recent entry.

You will want to step through the application to discern what *it* is calling, and with what variable values, to cause the segfault. Helpfully, gdb() can step through an application (if built with debugging symbols) by function, by line-of-code, and even by compiled machine instruction. Line-of-code will be the most useful in such an exercise.

Code:

.....................................................................................
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/local/lib/gcc49/libstdc++.so.6...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/gcc49/libstdc++.so.6]
.......................................................................................

i willl rebuild with debug , later today...

jggimi · 01-31-2017, 08:39 AM

Disclaimer. I don't use FBSD, as you know. But I find this an interesting message from gdb().

Code:

Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/gcc49/libstdc++.so.6]

A quick internet search indicates this may cause problems for the gdb() you are using. There may be a port/package of a different version of gdb() for FBSD which can read the symbols from that library.

Or perhaps you can use your favorite tool and rebuild the library with a different version of DWARF symbols.

http://stackoverflow.com/questions/1...-4-should-be-2