Cezar (Jul 03 2018 at 21:43): Cezar (Jul 03 2018 at 21:43):there is a bug here. freesolid is iterated, the head element is removed, and then added again, resulting in an infinite loop. i don't know how to fix it, since i don't know what it's actually trying to accomplish
Sean (Jul 04 2018 at 04:51):there is a bug here. freesolid is iterated, the head element is removed, and then added again, resulting in an infinite loop. i don't know how to fix it, since i don't know what it's actually trying to accomplish
I'm not seeing it -- can you explain? are you referring to RT_G_DEBUG mode on line 738? that can be deleted if it's gotten out-of-date.
Cezar (Jul 04 2018 at 05:26):FREE_SOLID (https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/include/rt/solid.h#l81) also does a BU_LIST_APPEND of sp (which has just been dequeued) to freesolid (from which it has just dequeued sp)
Cezar (Jul 04 2018 at 05:28):it's true that RT_G_DEBUG has to be on. i ran an mged test with -x 801 -X 801 and stumbled upon the issue
Sean (Jul 04 2018 at 05:52):I think that's code that got out of sync with other code. There almost certainly was other RT_G_DEBUG code that has since been deleted that make it work right. The "fix" is to probably just delete this offending code. We should not be doing manual data-specific pooling (freelists) like that any more. They're crazy slow, incoherent, pointer chasing.
Cezar (Jul 04 2018 at 07:17):i removed the code in r71109. i ran the tests before committing, everything was fine
Cezar (Jul 09 2018 at 12:01):regress-rtwizard-rtwiz_m35_D fails on mac, but not on linux. here's the output of pix-cmp -l and here are the different pixels (using imagemagick). any suggestions on how i could debug this? i get the same results on both release and debug
Cezar (Jul 09 2018 at 12:03):@Sean should i pursue this further, or should i focus on the SoA work for now?
Sean (Jul 10 2018 at 03:26):@Sean should i pursue this further, or should i focus on the SoA work for now?
@Cezar if you would like to debug this, please do - it's some relatively recent change. you might have a good chance finding it simply by bisecting commits until you find the culprit.
I'm also seeing the failure on mac.
Sean (Jul 10 2018 at 03:30):all of the differences are subtle shading changes at extreme angles (e.g., 0/0/0 vs 2/2/2 rgb values on the tire edges), implying something has changed mathematically somewhere. i have a mini backlog of commits I've not yet peer-reviewed, so I'll try to keep an eye out for likely cause but typically will be something like subtle bounding box change via redefinition of INFINITY, optimized math rounding, error accumulation, etc
Cezar (Jul 10 2018 at 08:20):i tried with 7.26.4 from sourceforge, the test still fails. 7.26.0 doesn't build and i didn't try to fix it. it's either not that new, or maybe clang's libc++ could be at fault? i'll try building with -stdlib=libstdc++
Cezar (Jul 10 2018 at 08:22):i'll try building with clang on linux next, hopefully that uses libc++ and not the gnu one. i tried gcc 8 on mac, but lld can't link stuff (something about unrecognized options), and gnu ld doesn't produce mach-o's
Sean (Jul 10 2018 at 15:56):i tried with 7.26.4 from sourceforge, the test still fails. 7.26.0 doesn't build and i didn't try to fix it. it's either not that new, or maybe clang's libc++ could be at fault? i'll try building with -stdlib=libstdc++
@cezar It's typically better when hunting for bugs to go by commit revisions, not releases, so you can linearly walk back in time until you find when it last worked/broke. That's the bisecting I referred to as it's a typical workflow for both svn and git (though slightly different for each). That said, it's sounding like this might be a little too far down the rabbit hole for you right now, so I'd say just move on and I'll take a look.
Cezar (Jul 10 2018 at 15:58):i know how to do that with revisions, it’s what i did with the flto bug a few days ago, but in this case, i went to r69000 and it was still failing, so i was curious if the release was ok or not :D
Cezar (Jul 10 2018 at 16:00):would you like me to submit a bug report, maybe, so it’s not forgotten about?
Sean (Jul 10 2018 at 16:01):no, don't bother
Sean (Jul 10 2018 at 16:01):it won't be forgotten -- it's failing make test, so we can't release until it's fixed
Sean (Jul 10 2018 at 16:02):obviously slipped through on 7.26.4, but now we know about it -- you could add a line to the TODO file's top section as those are release blockers
Peter Pronai (Aug 07 2018 at 19:11):ran into this
mged> search / | / ERROR: bad pointer 0x5629bc520f18: s/b db_full_path(x64626670), was librt directory(x5551212), file /home/rain/Sync/gsoc/build/svn-master/src/librt/db_fullpath.c, line 264 ERROR: bad pointer 0x5629bc520f18: s/b db_full_path(x64626670), was librt directory(x5551212), file /home/rain/Sync/gsoc/build/svn-master/src/librt/db_fullpath.c, line 264 Saving stack trace to mged-5688-bomb.log
starseeker (Aug 08 2018 at 02:15):confirmed, I can reproduce it.
starseeker (Aug 08 2018 at 03:00):@Peter Pronai can you explain to me again why you're thinking the hole syntax needs changing?
starseeker (Aug 08 2018 at 03:03):OK, r71438 should take care of that crash.
Peter Pronai (Aug 08 2018 at 22:27):it doesn't necessarily, not with the latest patch
Peter Pronai (Aug 08 2018 at 22:32):
ran into this by clicking around randomly in the manpage viewer in MGED
Peter Pronai (Aug 08 2018 at 22:33):it keeps changing and stealing focus and i can't check out the Details>> thing or do anything but kill MGED
Peter Pronai (Aug 08 2018 at 22:33):it basically DOSes one's desktop
Peter Pronai (Aug 08 2018 at 22:33):no idea what the cause is but i'm more concerned about error messages being able to "DOS"
Peter Pronai (Aug 08 2018 at 22:34):there should be One (1) error window where all errors are collected and the user can scroll back and stuff
Peter Pronai (Aug 08 2018 at 22:35):something like Unity's log window is a good example (the game engine)
Peter Pronai (Aug 08 2018 at 23:21):since that's a bit vague, what happens more precisely is:
the node ID keeps incrementing in the error message, so telling it to skip the message doesn't because (i assume) each message counts as different due to the different ID
starseeker (Aug 09 2018 at 01:45):hmm. does that error appear right away or after clicking on a few man pages?
starseeker (Aug 09 2018 at 01:47):I can't seem to get that error, although I can get an error when I try to follow a hyperlink...
Peter Pronai (Aug 09 2018 at 02:15):never right away, i had to click on a number of pages on the left and idk which one triggered it
Peter Pronai (Aug 09 2018 at 02:15):sometimes it's only ~20 clicks, sometimes a lot more
starseeker (Aug 09 2018 at 02:16):that may be some quirk in the tkhtml widget - it's still kinda got wires sticking out around the edges in some respects.
Sean (Aug 09 2018 at 06:46):it basically DOSes one's desktop
what's going on is you're generating mouse events on that window every time you move the mouse (and there's obviously some problem in the event handler that causes the dialog to pop up). there are probably LOTS of events queued up, and every time you click a button or move the mouse to dismiss the panel, even more events are generated (dozens, maybe hundreds). if you took the window out of full screen and moved it out of the way from the dialog so the mouse doesn't go over it, you could probably clear out all the dialogs (which would clear out all the pending events)..
Sean (Aug 09 2018 at 06:46):there should be One (1) error window where all errors are collected and the user can scroll back and stuff
completely agree
Daniel Rossberg (Oct 13 2022 at 17:56):Open toyjeep.g in mged + e all.
Related to https://github.com/BRL-CAD/brlcad/commit/30e45f823ceca8c37fc7591c2bcf37f628471724 ?
starseeker (Oct 14 2022 at 01:50):I just tried with latest main and it seems to draw the wireframe - what are the symptoms you're seeing?
Daniel Rossberg (Oct 14 2022 at 08:40):Same for me, after https://github.com/BRL-CAD/brlcad/commit/9cd246294876ef3b757914c4e1dbf272b6751fd5 "Apparently we can't depend on cts_s.ts_dbip always being valid - try rti_dbip instead."
Daniel Rossberg (Oct 14 2022 at 08:51):BTW, I'm experiencing a build error with the new stepcode:
I'm seeing a kind of chicken or the egg dilemma in stepcode with expscan.h. The file is necessary to get generated. The work-around is to copy the file from the generated directory in the source tree to the ExpScanner_expscan directory in the binaries tree. It will be overwritten by the generated one then.
starseeker (Oct 14 2022 at 11:31):@Daniel Rossberg what failure are you seeing trying to draw? Is it crashing? Failing to create the wireframe correctly?
starseeker (Oct 14 2022 at 11:32):I'll have to try and set up a Debian Stable VM to see if I can reproduce - I've not encountered that stepcode failure mode on any of the testing so far, and I've not seen it from the github runners, so it's a little puzzling... that'll be a few days before I can attempt
Daniel Rossberg (Oct 14 2022 at 11:37):starseeker said:
Daniel Rossberg what failure are you seeing trying to draw? Is it crashing? Failing to create the wireframe correctly?
After your commit (I mentioned above), I don't get the error anymore. It should have fixed it. I meant with "same for me" that it draws the wireframe now. Before, I got a bad pointer message.
starseeker (Oct 14 2022 at 11:37):Ah - I thought you meant "same" as in "no change to error" :-)
starseeker (Oct 14 2022 at 11:40):@Daniel Rossberg I don't know if you can easily tell, but what in the initial build process is needing expscan.h? I'm wondering how that can be needed on just Debian stable...
starseeker (Oct 14 2022 at 11:41):It might be that there's something wonky with the perplex/lemon setup, which should be the only time generated gets involved...
Daniel Rossberg (Oct 14 2022 at 12:11):expscan.h is included in expparse.y. This is where the error comes from, during the generation phase, I think.
[ 26%] Creating directories for 'STEPCODE_BLD'
[ 26%] No download step for 'STEPCODE_BLD'
[ 26%] No update step for 'STEPCODE_BLD'
[ 26%] No patch step for 'STEPCODE_BLD'
[ 26%] Performing configure step for 'STEPCODE_BLD'
-- STEPCODE_BLD configure command succeeded. See also /home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/ext/STEPCODE_BLD-prefix/src/STEPCODE_BLD-stamp/STEPCODE_BLD-configure-*.log
[ 26%] Performing build step for 'STEPCODE_BLD'
CMake Error at /home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/ext/STEPCODE_BLD-prefix/src/STEPCODE_BLD-stamp/STEPCODE_BLD-build-.cmake:37 (message):
Command failed: 2
'make'
See also
/home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/ext/STEPCODE_BLD-prefix/src/STEPCODE_BLD-stamp/STEPCODE_BLD-build-*.log
-- stdout output is:
Scanning dependencies of target ExpParser_input_cpy
[ 0%] Generating expparse.y.sentinel
[ 1%] Generating expparse.y
[ 1%] Built target ExpParser_input_cpy
[ 1%] [LEMON][ExpParser] Building parser with /home/rossberg/Devel/BRL-CAD/build/brlcad/bin/lemon
Scanning dependencies of target objlib_expparse_c
[ 2%] Building C object src/express/CMakeFiles/objlib_expparse_c.dir/expparse.c.o
-- stderr output is:
In file included from expparse.y:5:
/home/rossberg/Devel/BRL-CAD/brlcad/src/other/ext/stepcode/src/express/parse_data.h:3:10: fatal error: expscan.h: Datei oder Verzeichnis nicht gefunden
3 | #include "expscan.h"
| ^~~~~~~~~~~
compilation terminated.
make[5]: *** [src/express/CMakeFiles/objlib_expparse_c.dir/build.make:86: src/express/CMakeFiles/objlib_expparse_c.dir/expparse.c.o] Fehler 1
make[4]: *** [CMakeFiles/Makefile2:1172: src/express/CMakeFiles/objlib_expparse_c.dir/all] Fehler 2
make[3]: *** [Makefile:149: all] Fehler 2
CMake Error at /home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/ext/STEPCODE_BLD-prefix/src/STEPCODE_BLD-stamp/STEPCODE_BLD-build-.cmake:47 (message):
Stopping after outputting logs.
make[2]: *** [src/other/ext/CMakeFiles/STEPCODE_BLD.dir/build.make:130: src/other/ext/STEPCODE_BLD-prefix/src/STEPCODE_BLD-stamp/STEPCODE_BLD-build] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:15471: src/other/ext/CMakeFiles/STEPCODE_BLD.dir/all] Fehler 2
make: *** [Makefile:182: all] Fehler 2
Putting PERPLEX_TARGET before LEMON_TARGET doesn't help.
starseeker (Oct 15 2022 at 01:08):I've seen an occasional, not reliably reproducible error that seems to be either a missing dependency specification or one of those situations were I/O operations aren't fully completing correctly. If you run "make" again after that error appears by going down into the build directory of the stepcode subbuild and manually running make, does it complete?
starseeker (Oct 15 2022 at 20:11):@Daniel Rossberg Let me know if 658f8329fc2d works/helps.
Daniel Rossberg (Oct 16 2022 at 15:32):I got a clean build now :smiley:
starseeker (Oct 17 2022 at 01:22):We'll want to make sure it works by running it for a while - if that's the issue I've seen it doesn't always manifest. If it consistently fixes it I'll push it upstream.
Daniel Rossberg (Oct 17 2022 at 13:20):I tested it on 3 machines before. On all, I got the same error. I applied your bugfix on two of them already. The builds on both are successful now.
Daniel Rossberg (Dec 13 2022 at 19:18):However, solving one problem mean to run into the next one. This is probably related to https://github.com/BRL-CAD/brlcad/commit/d6980c17fc16c6c694e561f6f8697d2e57d69f0e#diff-0a778b8459b95589232e39c837dc5217b2fb7d691baf5f7bc7601cda19c14dc7.
I open a GED handle with GED_INIT() and close it with ged_close but the wdbp handled to the init should be still intact after the GED handle was closed. Insted, I'm seeing an error like this
ERROR: bad pointer 0x55b1fa4ac120: s/b struct db_i(x57204381), was Unknown_Magic(xfa4a8250), file /home/rossberg/Devel/BRL-CAD/brlcad/src/librt/db_open.c, line 352
@Daniel Rossberg Looking at the previous (7.32.6) release (https://github.com/BRL-CAD/brlcad/blob/rel-7-32-6/src/libged/ged.c#L83) it looks like ged_close is calling wdbp_close. Also from the 7.32.6 release, GED_INIT is assigning the supplied wdbp to gedp->ged_wdbp (https://github.com/BRL-CAD/brlcad/blob/rel-7-32-6/include/ged/defines.h#L105)
Naively, my expectation would be that a wdbp passed to GED_INIT and then subjected to ged_close wouldn't be expected to be valid? Perhaps I'm missing something...
Daniel Rossberg (Dec 16 2022 at 21:56):Maybe. I never really tested it. What I did is
resource* resp_db = static_cast<resource*>(bu_calloc(1, sizeof(resource), "resp_db"));
rt_init_resource(resp_db, 0, NULL);
struct db_i* dbip = db_open(fileName, "rw");
db_dirbuild(dbip);
rt_wdb* wdbp_db = wdb_dbopen(dbip, RT_WDB_TYPE_DB_DISK);
rt_i* rtip_db = rt_new_rti(wdbp_db->dbip);
rt_init_resource(resp_db, 0, rtip_db);
I.e., resp_db, rtip_db, and wdbp_db are my variables used for the writable database.
ged* gedp_ged;
BU_GET(gedp_ged, ged);
GED_INIT(gedp_ged, wdbp_db);
ged_close(gedp_ged);
wdb_close(wdbp_db);
rt_free_rti(rtip_db);
rt_clean_resource_complete(0, resp_db);
bu_free(resp_db, "resp_db");
I get the error in rt_free_rti (db_close_client). Maybe, I should make a copy first and hand this over to GED_INIT?
Daniel Rossberg (Dec 16 2022 at 22:58):BTW, why does GED_INIT call ged_init twice?
Benjamin Fennell (Nov 08 2024 at 15:16):I am having some issues with the tgc primitive. Do the vectors A and B have to be perpendicular to one another? If they are not perpendicular, then rt will seemingly not render them.
To illustrate what I mean, the following two photos should help:
file.png
tgc-rt.png
As you can see, the wire-frame shows up just fine, but rt will not render tgcs which do not have its vectors A and B perpendicular to one another. Here are the parameters for the four tgcs:
tgc1.s: in tgc1.s tgc 0 -50 0 0 0 50 10 0 0 0 10 0 10 10
tgc2.s: in tgc2.s tgc 0 -30 0 0 0 50 10 0 0 0 5 0 5 10
tgc3.s: in tgc3.s tgc 0 0 0 0 0 50 10 10 0 -10 10 0 5 5
tgc4.s: in tgc4.s tgc 0 30 0 0 0 50 10 10 0 -10 8 0 5 5
Additionally, here is the database:
tgc.g
Do I simply not understand how the tgc primitive works? I am pretty new to using BRL-CAD, so this could be the case.
Daniel Rossberg (Nov 10 2024 at 16:55):I looks like this is the reason. If you look at the rt text output, you can see the lines
tgc(tgc4.s): A not perpendicular to B, f=-0.110432
tgc: dot=-20 / a*b=181.108
_rt_gettree_leaf(tgc4.s): prep failure
_db_walk_subtree() FAIL on '/tgc4.s'
rt_gettrees() cleaning up dead solid 'tgc4.s'
I see, I should have looked at the rt output more thoroughly.
Thank you!
Benjamin Fennell (Nov 23 2024 at 21:21):I may have found a bug with the clone command.
When the name of a primitive or object that is being cloned starts with a number the resultant clones do not inherit a full name. The following is an example:
Input: clone 1Test.s
Output Name: 100
It should be noted that this only occurs if the name starts with a number. Which is why the following behaves normally:
Input: clone a-1-Test.s
Output Name: a-101-Test.s
I am not sure if this has already been fixed or not, since I am currently using the binary release.
Here is the database that contains the examples:
TEMPDB.g
PS. Upon further testing, it would seem that there is a potentially different issue when cloning combinations. The following may help illustrate:
Input: comb combination1.c u test.s u 1test.s
Input: clone combination1.c
Output name: combination2
It would seem that, when dealing with combinations, regardless of where the number is in the name, the name gets truncated after the number to be incremented.
I will continue to play around with it, and probably try a few different options with clone as well.
Benjamin Fennell (Dec 02 2024 at 10:58):I may have potentially found a bug with rt's rendering. Here are two images that may help illustrate:
Bugged rendering. bugged-projection.png
Workaround rendering. workaround-projection.png
The bugged rendering is drawing the cut plate beyond its actual dimensions. The workaround that I found was to make the cut plate larger in the Z axis, then to cut off the rest of what I did not need.
Here are the two databases that generated those images:
BuggedDB.g
WorkaroundDB.g
I encountered this bug while scripting BRL-CAD, so I also have scripts which can automatically generate both databases and the above images:
workaroundBugReport.sh
bugReport.sh
Note, it is assumed that when running these scripts you are in a directory that contains the mged binary.
Finally, I should mention that I am using the binary distribution, so perhaps this bug has already been fix.
Daniel Rossberg (Dec 02 2024 at 13:08):It looks like this is a precision issue. Putting units m; as first command in the mged script seams to resolve it.
Benjamin Fennell (Dec 02 2024 at 14:51):Oh I see. it was using millimeters by default, and that was too small; similarly micrometers also don't work, since they to are too small. Thanks for your help!
Last updated: Jan 09 2025 at 00:46 UTC