Segment Fault on Windows 11 Pro WSL Ubuntu 24.04.4 LTS

[open-stemware]

I had successfully been running in the (Windows 11 Pro WSL Ubuntu 24.04.4 LTS) environment but after I did an Ubuntu sudo apt update and sudo apt upgrade -y 42 crashed. I was running 42 with the Demo. Blank windows appeared and about 10 seconds later I got a segmentation fault.

I traced the issue in the debugger

and the fault occurs in the glut main loop

[ericstoneking]

So, 42 used to work, then you updated Ubuntu, and now 42 crashes... I have no idea, but here are the things I would try.

First, "make clean", "make". I always make clean when things break for no apparent reason.

Next, try updating/refreshing/reinstalling freeglut3-dev. Maybe something in the Ubuntu upgrade broke something in freeglut.

Last, try building with glfw instead of glut. Look in the Makefile for GLUT_OR_GLFW. make clean again, of course.

If those don't work, deeper investigation will be needed. It looks like a problem with opengl/glut, but isolating it might be difficult.

[open-stemware]

Thanks Eric. I tried your suggestions but no luck.

I wrote the issue not really expecting an answer but rather to capture the configuration/problem so if other people experience issues, we can find commonality and hopefully solve it. One thing I left out was the openGL version which is "OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.2.8-0ubuntu0.24.04.1".

I suspect there's a lurking memory problem that got exposed with my particular configuration. I had another ubuntu VM handy that has OpenGL 3.1 installed and it runs successfully.

I'll do some debugging...

[open-stemware]

Below are a few memory related issues I’ve found but there are remaining heap corruption issues that I don’t have time to pursue at the moment. I’ve attached a valgrind report and output after a crash when 42 was built using gcc -fsanitize=address. These outputs are after I made the following changes. My changes are commented with //dcm in the attached code and the line numbers should line up with the reports.

1. Glkit.c: LoadFont8x11()
   a. Changed “Offset = glGenLists(95);” to Offset = glGenLists(128);
   b. The for loop (i = 0,j = ' '; i < 95; i++,j++) has J starting at 32 so it will overrun the allocated list of 95.
2. Glkit.c: LoadEgretCatalog ()
   a. GammaSource[i].Color[3] is not initialized before it is passed to glColor4fv()
3. 42report.c: Report():
   a. Updated char s[40]; to char s[80];
   b. With stricter compiler settings I got warnings this could overflow. I didn’t see an example when I thought it would overrun but easier just to change it. Valgrind was also reporting runtime issues in this function and if I didn’t run Report() it didn’t crash.

42-fsantitizer.txt
42-valgrind.txt

42gl.c
42glut.c
42report.c
glkit.c

[ericstoneking]

Hi Dave,

Your suggestions have been incorporated and pushed to the repo. I don't see why the LoadFont8x11 thing overran, but it's a cheap fix.

Regards,
-Eric

[msuder]

For what it is worth, I turned "Shadows" to FALSE in the Inp_Graphics.txt file and can get 42 to run the Demo scenario without segfaulting on WSL2.

[open-stemware]

Stack overflow may also be at play.

[msuder]

I don't know why, but commenting out line 4999 of 42glut.c fixes the problem... no more seg fault.

[ericstoneking]

Commenting that out disables shadows altogether on my setup.

[zlynch2]

Also Note: it seems using freeglut3-dev version 2.8.1-6 works but freeglut3-dev version 3.4.0-1 requires the comment or shadows disabled to work.

Freeglut3-dev is an alternative to openGL. Our nos3 container uses version 2.8.1-6 but when I run 42 without our container with the latest version (3.4.0) thats when we see the segfault.

WSL may see similiar results. I was testing running on my mac with an arm64 ubuntu version 24.04. Also Note 42 runs natively on macOS with the default openGL library installed (maybe 4.1?)

[open-stemware]

In the 42-fsantitizer.txt file I attached earlier it states the crash occurs when an attempt is made to access a freed memory space. The memory was allocated by OpaquePass() in 42gl.c.

I haven't used openGL, so I'll ask the experts...

In between multiple glPushMatrix() and glPopMatrix() calls the following logic is performed
if (ShadowsEnabled) {
MxM4f(ShadowFromNMatrix, ..., ShadowMatrix);
glUniformMatrix4fv(ShadowMatrixLoc,1,0,ShadowMatrix);
}

Does the glUniformMatrix4fv() impact the gl matrix push and pops?

[ericstoneking]

I don't see how, but that can be said about a lot of this.

glUniformMatrix4fv is copying the 16-element array ShadowMatrix onto the GPU so that the shader can find it. The "Uniform" part means that it will be applied to all pixels by the shader. I don't see any allocations involved.

I guess the push/pop process could alloc/free stuff. Your 42-fsanitizer file says the region that was allocated in OpaquePass is 40 bytes. I don't see anything involved that would obviously be that size.

[ericstoneking]

I just pushed three changes:

1. Only pass printable characters to glutBitmapCharacter. The intent is to avoid pointing to unintended places.
2. I placed some commented-out diagnostic printf statements in DrawBitmapString. Uncomment as desired to gather insights about what is being processed.
3. There were some display lists being loaded that don't get used, so I commented out the load to reduce memory usage.

[ericstoneking]

I just pushed a raft of allocation error traps. Let me know if anything changes.