@Sean When I tried to install mged 7.30.8, shows an error image.png
@Sean Why is that?
Ran it as administrator.
It worked, I think.
running something as administrator fixes many things most of the time but it has its own risk....
Yeah
Usually setups run on normal click
But for this one
@Sean Do you happen to know what the "inmem" wdb_open is for on mged.c:2826? I'm having a heck of a time figuring out what it does - I only see one use of .inmem in the Tcl code - ray.tcl - and I'm not really clear what it's trying to accomplish with that or if we need .inmem to do whatever it's trying to do... It goes back a long way in the repo - SVN r13946 in fact. I think that code might be why we've got two wdbp instances floating around in MGED.
there used to be an in-memory concept of db way back to facilitate distributed raytracing, iirc. could it be related to that?
Yeah, that one has quite a bit of history. Basically, it's an in-memory database where geometry can be loaded but everything is ephemeral (and crazy fast). If I remember right, Bob only hooked it into a couple things in mged, but the idea is that it's a copy of the database that only lives in memory so you can do prep on some geometry and you don't have to do it again, and there's no way to affect the .g by subsequent changes -- but you can still make changes.
So in the case of ray.tcl, that's a routine used in a surprising number of places. It's how it queries what's under the mouse (by shooting a ray), which is one of the comb and primitive input selection methods, which is not just bound through in the tcl gui, but it's also hooked into classic mode through to the dm graphics window. By using inmem, prep only happens once.
Note that the inmem doesn't really consume additional resources as it's an in-memory reopening of the same dbip. It's just tracked quite differently when changes are made. That's actually the same interface that's provided to ajem for dynamic geometry. The inmem is used for geometry changes that are desirable to be persisted to disk, and being in the inmem dbip, it can't even by accident down the road.
I have a very bad feeling about https://github.com/BRL-CAD/brlcad/commit/abcba83f77babcccd0b9b7074037a424a2539c46. It breaks applications working with real in-memory databases, e.g. via the C++ interface. Fixing this would be a mess.
@Daniel Rossberg how does it break in-memory databases? I didn't remove that mode of operation, as far as I know... (note there are a lot of commits after that one related to that particular refactor as well - is current main broken?)
After looking at my problem in the debugger, I have to admit, that I don't come so far to open a database.
What I try to do is open a database and getting its title. My last change was related to dbi_wdbp_inmem.
However, I don't even reach main() now. The program crashes in ON_wString::ReserveArray() during libged_init() with a segmentation fault.
0x00007ffff546fba7 in ON_wString::ReserveArray(unsigned long) () from /home/rossberg/bin/MOOSE/lib/libbrlcad.so
(gdb) bt
#0 0x00007ffff546fba7 in ON_wString::ReserveArray(unsigned long) () from /home/rossberg/bin/MOOSE/lib/libbrlcad.so
#1 0x00007ffff546fffa in ON_wString::CopyToArray(int, wchar_t const*) () from /home/rossberg/bin/MOOSE/lib/libbrlcad.so
#2 0x00007ffff5470b95 in ON_wString::operator=(wchar_t const*) () from /home/rossberg/bin/MOOSE/lib/libbrlcad.so
#3 0x00007ffff06a2b01 in ON_FontList::Internal_FromNames (this=0x7ffff0b4ebe0 <ON_ManagedFonts::List+256>,
postscript_name=0x55555558728c L"ArialMT", windows_logfont_name=0x55555558722c L"Arial", family_name=0x55555558714c L"Arial",
prefered_face_name=0x5555555871ac L"Regular", prefered_weight=ON_Font::Weight::Normal, prefered_stretch=ON_Font::Stretch::Medium,
prefered_style=ON_Font::Style::Upright, bRequireFaceMatch=true, bRequireStyleMatch=true, bMatchUnderlineStrikethroughAndPointSize=false,
bUnderlined=false, bStrikethrough=false, point_size=0) at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_font.cpp:4411
#4 0x00007ffff06a28c8 in ON_FontList::FromNames (this=0x7ffff0b4ebe0 <ON_ManagedFonts::List+256>, postscript_name=0x55555558728c L"ArialMT",
windows_logfont_name=0x55555558722c L"Arial", family_name=0x55555558714c L"Arial", prefered_face_name=0x5555555871ac L"Regular",
prefered_weight=ON_Font::Weight::Normal, prefered_stretch=ON_Font::Stretch::Medium, prefered_style=ON_Font::Style::Upright,
bRequireFaceMatch=true, bRequireStyleMatch=true) at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_font.cpp:4323
#5 0x00007ffff06a3a4c in ON_FontList::FromFontProperties (this=0x7ffff0b4ebe0 <ON_ManagedFonts::List+256>,
font_properties=0x7ffff0b4eda0 <ON_Font::Default>, bRequireFaceMatch=true, bRequireStyleMatch=true)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_font.cpp:4751
#6 0x00007ffff06a82a4 in ON_Font::Internal_CopyFrom (this=0x7ffff0b4eda0 <ON_Font::Default>, src=...)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_font.cpp:6265
#7 0x00007ffff06a8f49 in ON_Font::ON_Font (this=0x7ffff0b4eda0 <ON_Font::Default>, src=...)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_font.cpp:6435
#8 0x00007ffff0894352 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_statics.cpp:1425
#9 0x00007ffff0895988 in _GLOBAL__sub_I_opennurbs_statics.cpp(void) ()
at /home/rossberg/Devel/BRL-CAD/brlcad/src/other/openNURBS/opennurbs_statics.cpp:3018
#10 0x00007ffff7fe1fe2 in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe508, env=env@entry=0x7fffffffe520)
at dl-init.c:72
#11 0x00007ffff7fe20e9 in call_init (env=0x7fffffffe520, argv=0x7fffffffe508, argc=2, l=<optimized out>) at dl-init.c:30
#12 _dl_init (main_map=0x55555557e410, argc=2, argv=0x7fffffffe508, env=0x7fffffffe520) at dl-init.c:119
#13 0x00007ffff452aaed in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>)
at dl-error-skeleton.c:182
#14 0x00007ffff7fe6058 in dl_open_worker (a=a@entry=0x7fffffffd040) at dl-open.c:758
#15 0x00007ffff452aa90 in __GI__dl_catch_exception (exception=0x7fffffffd020, operate=0x7ffff7fe5ca0 <dl_open_worker>, args=0x7fffffffd040)
at dl-error-skeleton.c:208
#16 0x00007ffff7fe58fa in _dl_open (file=0x7fffffffd3e0 "/home/rossberg/bin/brlcad/libexec/ged/libged-3ptarb.so", mode=-2147483646,
caller_dlopen=0x7ffff4f84803 <bu_dlopen+47>, nsid=-2, argc=2, argv=0x7fffffffd020, env=0x7fffffffe520) at dl-open.c:837
#17 0x00007ffff43d2258 in dlopen_doit (a=a@entry=0x7fffffffd260) at dlopen.c:66
#18 0x00007ffff452aa90 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffd200, operate=0x7ffff43d2200 <dlopen_doit>,
args=0x7fffffffd260) at dl-error-skeleton.c:208
#19 0x00007ffff452ab4f in __GI__dl_catch_error (objname=0x55555557e3f0, errstring=0x55555557e3f8, mallocedp=0x55555557e3e8,
operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:227
#20 0x00007ffff43d2a65 in _dlerror_run (operate=operate@entry=0x7ffff43d2200 <dlopen_doit>, args=args@entry=0x7fffffffd260) at dlerror.c:170
--Type <RET> for more, q to quit, c to continue without paging--
#21 0x00007ffff43d22e4 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#22 0x00007ffff4f84803 in bu_dlopen (path=0x7fffffffd3e0 "/home/rossberg/bin/brlcad/libexec/ged/libged-3ptarb.so", mode=2)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/libbu/dylib.c:47
#23 0x00007ffff4a7e671 in libged_init () at /home/rossberg/Devel/BRL-CAD/brlcad/src/libged/ged_init.cpp:183
#24 0x00007ffff4a7f05e in libged_initializer::libged_initializer (this=0x7ffff573afd0 <LIBGED>)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/libged/ged_init.cpp:280
#25 0x00007ffff4a7ed7c in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /home/rossberg/Devel/BRL-CAD/brlcad/src/libged/ged_init.cpp:289
#26 0x00007ffff4a7edd3 in _GLOBAL__sub_I_ged_init.cpp(void) () at /home/rossberg/Devel/BRL-CAD/brlcad/src/libged/ged_init.cpp:289
#27 0x00007ffff7fe1fe2 in call_init (l=<optimized out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe508, env=env@entry=0x7fffffffe520)
at dl-init.c:72
#28 0x00007ffff7fe20e9 in call_init (env=0x7fffffffe520, argv=0x7fffffffe508, argc=2, l=<optimized out>) at dl-init.c:30
#29 _dl_init (main_map=0x7ffff7ffe180, argc=2, argv=0x7fffffffe508, env=0x7fffffffe520) at dl-init.c:119
#30 0x00007ffff7fd30ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#31 0x0000000000000002 in ?? ()
#32 0x00007fffffffe85f in ?? ()
#33 0x00007fffffffe8ae in ?? ()
#34 0x0000000000000000 in ?? ()
That call stack is coming from OpenNURBS, so my first thought is that something about the new OpenNURBS version isn't playing nicely with the library initialization.
(Assuming you're working with main and not the 7.34.0 release?)
Does MGED work from that build on that machine?
starseeker said:
(Assuming you're working with main and not the 7.34.0 release?)
Right.
starseeker said:
Does MGED work from that build on that machine?
MGED works.
The point is, after some recompilations and tests, the error is gone. Was a clean build necessary? I saw this error on several machines. I'll have to look at them when I'm back.
Last updated: Jan 09 2025 at 00:46 UTC