mainSCM Scheme Implementation - Support: sr #111003, Multiple valgrind-errors in...


sr #111003: Multiple valgrind-errors in igc()->mark_locations()

Submitter:  None
Submitted:  Sat 06 Jan 2024 08:48:02 PM UTC
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  *BSD
* Mandatory Fields

Add a New Comment Rich Markup

Sat 06 Jan 2024 08:48:02 PM UTC, original submission:  

The self-tests bundled with scm break for some of the FreeBSD architecture/compiler combinations.

For example, here is the build/testing log showing a self-test failure on i386 compiled with clang-16.

While investigating the above failure, I attempted to run the failing command-line on FreeBSD/amd64. Although the test completes fine on this combination, using valgrind I can see numerous cases of using uninitialized values. These all seem to come from gc_for_newcell() calling igc() calling mark_locations() -- all in sys.c.

For example, the very first error here is (the exact line-numbers may differ depending on the patching):

==29448== Conditional jump or move depends on uninitialised value(s)
==29448==    at 0x2489CA: mark_locations (sys.c:2643)
==29448==    by 0x246F23: igc (sys.c:2417)
==29448==    by 0x24337D: gc_for_newcell (sys.c:2268)
==29448==    by 0x242C1A: cons (sys.c:1472)
==29448==    by 0x227717: scm_lreadparen (repl.c:1144)
==29448==    by 0x226BB8: scm_lreadpr (repl.c:901)
==29448==    by 0x22774A: scm_lreadparen (repl.c:1146)
==29448==    by 0x226BB8: scm_lreadpr (repl.c:901)
==29448==    by 0x22774A: scm_lreadparen (repl.c:1146)
==29448==    by 0x226BB8: scm_lreadpr (repl.c:901)
==29448==    by 0x22774A: scm_lreadparen (repl.c:1146)
==29448==    by 0x226BB8: scm_lreadpr (repl.c:901)

I will not pretend to understand that code, but it seems like it is trying to determine, whether a pointer points at a valid cell based simply on the pointer's alignment (that's all the NCELLP() is looking at). Is not that an inherently flawed approach?

Note, that scm is already compiled without optimization here -- using an explicit -O0 compiler-flag.

The full set of patches applied to 5f3 on FreeBSD can be found in the software port's files/ subdirectory, but the valgrind errors persist even if the patches are not applied...

I'm not including the full debug logs, because it'd be a lot simpler for you to reproduce the problem locally: just build scm with debugging (using flags like -O0 -g) and run something like:

valgrind ./scm "-rmacro" "-fsyntest1.scm" "-fsyntest2.scm" "-fr4rstest.scm" "-e(test-sc4)(test-cont)(test-delay)" "-fsyntest1" "-e" "(or (null? errs) (quit 1))"



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code