search

seeing-things / zwo

ZWO SDK and custom software for debugging and using it.
24 stars 4 forks source link

#25: Add dynamic version detection & generally make things nicer/better #26

Closed jgottula closed 5 years ago

jgottula commented 5 years ago

This is a large refactoring of zwo_fixer, and it really cleans things up, in my opinion.

Most notably, the ASI SDK version configuration is no longer statically determined at compile-time by the Makefile. Instead, at runtime, the code detects the ASI library in memory; determines its version; checks if that version is known and supported; and then proceeds to use the appropriate offsets for that particular version.

I changed a huge chunk of how the initialization code works, so this definitely needs some real testing to ensure that I didn't break anything horribly. Ideally it should be compiled once, and then tested against two different versions of capture (one linked against ASI 0.7.0503, and one linked against ASI 1.14.0715). Ideally it should handle the two different ASI SDK versions without any issues.

bgottula commented 5 years ago 
(gdb) run
Starting program: /home/rgottula/dev/zwo/capture/bin/capture 
warning: the debug information found in "/lib64/ld-2.23.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fb4b04 in __static_initialization_and_destruction_0 (
    __initialize_p=__initialize_p@entry=1, __priority=__priority@entry=65535)
    at internal.hpp:206
206     return (s_Loaded && s_Supported);
(gdb) bt
#0  0x00007ffff7fb4b04 in __static_initialization_and_destruction_0 (
    __initialize_p=__initialize_p@entry=1, __priority=__priority@entry=65535)
    at internal.hpp:206
#1  0x00007ffff7fb4d33 in _GLOBAL__sub_I_zwo_fixer.cpp(void) ()
    at zwo_fixer.cpp:96
#2  0x00007ffff7de76ca in call_init (l=<optimized out>, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffdf58, env=env@entry=0x7fffffffdf68)
    at dl-init.c:72
#3  0x00007ffff7de77db in call_init (env=0x7fffffffdf68, argv=0x7fffffffdf58, 
    argc=1, l=<optimized out>) at dl-init.c:30
#4  _dl_init (main_map=0x7ffff7ffe168, argc=1, argv=0x7fffffffdf58, 
    env=0x7fffffffdf68) at dl-init.c:120
#5  0x00007ffff7dd7c6a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000000000001 in ?? ()
#7  0x00007fffffffe277 in ?? ()
#8  0x0000000000000000 in ?? ()
jgottula commented 5 years ago

Okay thanks.

Looks like there’s an issue here regarding either C++’s undefined static initialization ordering, or possibly the order in which the shared libraries are being loaded.

Not too surprising, and I was a bit suspicious that this could happen, even though the one or two quick tests that I did do did work. (The ordering can vary based on a lot of seemingly minor or insignificant factors if you don’t have it set up just right.)

I’ll take a closer look at it.