linux-x86 gcc 3.3.2 kernel 2.4.23 after successful make (despite many warnings) and install of Mesa, followed by install of NVIDIA-6111 replacing libGL and glx*.h where conflicts exist: /usr/lib /usr/local/lib /usr/local/include/GL Now, a couple applications give Segmentation Faults GNU gdb 6.3 (gdb) run Starting program: /usr/local/bin/Atlas [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 31683)] Please wait while loading databases...done. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31683)] 0x40044533 in glutGetWindow () from /usr/local/lib/libglut.so.3 Current language: auto; currently c (gdb) run Starting program: /usr/local/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 31705)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 31705)] 0x400a7533 in glutGetWindow () from /usr/local/lib/libglut.so.3 # ls -l /usr/[local/]lib/libglut* -rwxr-xr-x 1 root root 636608 Jul 4 2001 libglut.so.3.7.0* -rwxr-xr-x 1 root root 317635 Feb 2 16:37 libglut.so.3.7.1* lrwxrwxrwx 1 root root 12 Feb 2 16:37 libglut.so -> libglut.so.3 lrwxrwxrwx 1 root root 17 Feb 3 09:37 libglut.so.3 -> libglut.so.3.7.1 the new library is smaller, optimized perhaps. # nm libglut.so.3.7.0 | grep -e __glutWindowCache 00030fc0 d __glutWindowCache # nm libglut.so.3.7.1 | grep -e __glutWindowCache 00039c40 b __glutWindowCache Oh, so that's where the size difference came from. Well, that's not the source of the problem, fortunately... (even if my brother thinks it's a very bad optimization to make, assuming that the OS will pre-clear the memory pages...) We found that adding a small delay in src/glut/glx/glut_win.c within the function prototyped int GLUTAPIENTRY glutGetWindow(void) keeps the apps from giving a seg fault. BUT it also reduced the performance, until making the delay a single time slice. Apparently NVidia's driver takes longer than what glut expects to initialize the screen? Another test 'solution' was to remove the symlink libglut.so.3 and point it back to mesa-3.4 version of libglut.so.3.7.0; FlightGear and Atlas worked again after this change, so the problem was clearly something to do with libglut. My brother then worked with it a while, trying to find out just how much of a delay was necessary. Here's his patch: ****** ---- cut ---- ***** --- Mesa-6.2.1/src/glut/glx/glut_win.c Wed Feb 12 15:56:23 2003 +++ MesaChanged/Mesa-6.2.1/src/glut/glx/glut_win.c Thu Feb 3 09:45:38 2005 @@ -40,6 +40,11 @@ static int numRequiredWindowCriteria = sizeof(requiredWindowCriteria) / sizeof( Criterion); static int requiredWindowCriteriaMask = (1 << LEVEL) | (1 << TRANSPARENT); +/* -------- added header: ----------------------- */ +#include <unistd.h> +static struct timeval toGUTS = {0,0}; +/* ----------------------------------- StevenA -- */ +
oops, something got cut off, here is the patch again. ****** ---- cut ---- ***** --- Mesa-6.2.1/src/glut/glx/glut_win.c Wed Feb 12 15:56:23 2003 +++ MesaChanged/Mesa-6.2.1/src/glut/glx/glut_win.c Thu Feb 3 09:45:38 2005 @@ -40,6 +40,11 @@ static int numRequiredWindowCriteria = sizeof(requiredWindowCriteria) / sizeof( Criterion); static int requiredWindowCriteriaMask = (1 << LEVEL) | (1 << TRANSPARENT); +/* -------- added header: ----------------------- */ +#include <unistd.h> +static struct timeval toGUTS = {0,0}; +/* ----------------------------------- StevenA -- */ + static void cleanWindowWorkList(GLUTwindow * window) { @@ -134,6 +139,7 @@ glutGetWindow(void) { if (__glutCurrentWindow) { + select(0, NULL, NULL, NULL, &toGUTS); return __glutCurrentWindow->num + 1; } else { return 0; ****** ---- cut ---- ***** Hopefully this will help.
I highly doubt this is a timing issue in GLUT. I'd recompile GLUT with debugging info, see if it crashes, then use gdb to get a stack trace. Basically: cd Mesa-6.2/ make realclean make linux-debug Then, copy the lib/libglut.* files to wherever you need them and try your app again.
Adding debug caused the seg fault to not occur. So I did a backtrace on the non-debug version of libglut.so.3.7.1 (gdb) run Starting program: /usr/local/bin/Atlas [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2502)] Please wait while loading databases...done. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2502)] 0x40044533 in glutGetWindow () from /usr/local/lib/libglut.so.3 Current language: auto; currently c (gdb) bt #0 0x40044533 in glutGetWindow () from /usr/local/lib/libglut.so.3 #1 0xbffff2d8 in ?? () #2 0x0807fab1 in puGetWindow () at pu.cxx:60 #3 0x0807fab1 in puGetWindow () at pu.cxx:60 #4 0x080844c0 in puObject (this=0x8122468, minx=1, miny=0, maxx=0, maxy=0) at puObject.cxx:155 #5 0x0807ff1b in puRealInit () at pu.h:871 #6 0x0804fe9c in init_gui (textureFonts=true) at /usr/include/plib/puGLUT.h:67 #7 0x08052ca0 in main (argc=1, argv=0xbffff6f4) at Atlas.cxx:1097 It occurs to us, that adding debug code, would change the timing. If it isn't a timing issue... why did the wait, regardless of it was caused by fprintf(), write(), or select(), fix the problem?
What happens when you run other GLUT programs with the non-debug library? Try a bunch of the programs in Mesa/progs/demos/
I can't get any seg faults from any of the demos. A few have errors, as listed below. /usr/src/Mesa-6.2.1/progs> mc > ./arbfplight Sorry, this demo requires GL_ARB_fragment_program > ./arbocclude Sorry, this demo requires the GL_ARB_occlusion_query extension > ./bounce > ./clearspd For options: ./clearspd -help Mode: RGB SwapBuffers: no Size: 400 x 400 Buffers: color Rate: 6400 clears in 2.426s = 2638.09 clears/s 4.22094e+08 pixels/s > ./cubemap GL_RENDERER: GeForce4 MX 440 with AGP8X/AGP/SSE GL_REFLECTION_MAP_ARB mode > ./fire Fire V1.5 96 fps > ./fogcoord fog(GL_FOG_COORDINATE_EXT) > ./fplight Sorry, this demo requires GL_NV_fragment_program > ./gamma > ./gears 4141 frames in 5.000 seconds = 828.200 FPS 4447 frames in 5.000 seconds = 889.400 FPS > ./geartrain 687 frames in 5.002 seconds = 137.345 FPS 685 frames in 5.002 seconds = 136.945 FPS > ./glinfo GL_VERSION: 1.5.1 NVIDIA 61.11 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_fence GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_register_combiners GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_lod GL_SUN_slice_accum GL_RENDERER: GeForce4 MX 440 with AGP8X/AGP/SSE GL_VENDOR: NVIDIA Corporation GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 5 GLUT_XLIB_IMPLEMENTATION: 15 > ./gloss 899 frames in 5.003 seconds = 179.692 FPS 933 frames in 5.003 seconds = 186.488 FPS > ./gltestperf GLTest v1.0 Written by David Bucciarelli Benchmark: 0 Elapsed time for the calibration test (30791): 2.000000 Selected number of benchmark iterations: 76977 Elapsed time for run 0: 3.443000 Elapsed time for run 1: 3.441000 Elapsed time for run 2: 3.438000 Elapsed time for run 3: 3.450000 Elapsed time for run 4: 3.475000 Simple Points 10726425.772028 Pnts/sec Benchmark: 1 Smooth Lines Current size: 480 Elapsed time for the calibration test (172): 2.004000 Selected number of benchmark iterations: 429 Elapsed time for run 0: 4.979000 Elapsed time for run 1: 4.916000 Elapsed time for run 2: 0.237000 Elapsed time for run 3: 0.216000 Elapsed time for run 4: 0.148000 SIZE=480 => 115060.523368 Lins/sec Current size: 250 Elapsed time for the calibration test (11543): 2.000000 Selected number of benchmark iterations: 28857 Elapsed time for run 0: 17.039000 > ./glutfx > ./ipers IperS V1.0 44 fps > ./isosurf 7179 vertices, 7177 triangles > ./lodbias Using GL_SGIS_generate_mipmap Level 0 size: 256 x 256 Level 1 size: 128 x 128 Level 2 size: 64 x 64 Level 3 size: 32 x 32 Level 4 size: 16 x 16 Level 5 size: 8 x 8 Level 6 size: 4 x 4 Level 7 size: 2 x 2 Level 8 size: 1 x 1 LOD bias range: [-15, 15] > ./morph3d > ./multiarb 2 texture units supported 2048 x 2048 max texture size > ./occlude Sorry, this demo requires the GL_HP_occlusion_test extension > ./osdemo ./osdemo: relocation error: /usr/local/lib/libOSMesa.so.6: undefined symbol: _tnl_run_pipeline > ./paltex > ./pixeltex Sorry, GL_SGIS_pixel_texture not supported by this renderer. > ./pointblast > ./ray Ray V1.0 75 fps > ./readpix GL_VERSION = 1.5.1 NVIDIA 61.11 GL_RENDERER = GeForce4 MX 440 with AGP8X/AGP/SSE Loaded 194 by 188 image Benchmarking... Result: 2730 reads in 4.000000 seconds = 24892140.000000 pixels/sec glDrawBuffer(GL_FRONT) > ./reflect 2785 frames in 5 seconds = 557 FPS 2868 frames in 5 seconds = 573.6 FPS > ./renormal > ./shadowtex Sorry, this demo requires the GL_ARB_depth_texture and GL_ARB_shadow extensions > ./spectex > ./spriteblast > ./stex3d GL_RENDERER: GeForce4 MX 440 with AGP8X/AGP/SSE GL_MAX_3D_TEXTURE_SIZE: 64 Current 3D texture size: 64 x 64 x 64 > ./teapot Teapot V1.2 98fps > ./terrain 150fps > ./tessdemo GLU version string: 1.3 > ./texcyl 3818 frames in 5 seconds = 763.6 FPS 3890 frames in 5 seconds = 778 FPS > ./texdown GL_VENDOR = NVIDIA Corporation GL_VERSION = 1.5.1 NVIDIA 61.11 GL_RENDERER = GeForce4 MX 440 with AGP8X/AGP/SSE w*h=65536 count=2369 time=3.000000 > ./texenv texenv - texture environment and internal format test > ./texobj > ./trispd For options: ./trispd -help Dither: on ShadeModel: smooth DepthTest: off Size: 50 pixels RedBits: 8 GreenBits: 8 BlueBits: 8 Rate: 24920064 tri in 3.966s = 6.28343e+06 tri/s 314171255 pixels/s Rate: 24920064 tri in 3.974s = 6.27078e+06 tri/s 313538802 pixels/s > ./tunnel Tunnel V1.5 162fps > ./tunnel2 Tunnel2 V1.0 49fps
The "Sorry, this demo requires XYZ" messages aren't errors. Some of the demos simply require OpenGL features that your driver doesn't support. I don't think your problem lies in GLUT. The glutGetWindow() function is extremely simple; I don't see how it could be at fault. I suggest you run your program with the 'valgrind' memory checker. If you have problems using it with your NVIDIA driver, be sure to read the valgrind-related info in /usr/share/doc/NVIDIA_GLX-1.0/README
Created attachment 1854 [details] output from valgrind for Segmentation Fault with Atlas Is this the tool type you were thinking of? looks like glut was being called thru plib-1.8.4 pu* functions
Hmmm, this is pretty weird. My best guess is that the __glutCurrentWindow variable is getting changed in some unusual way. Here's a patch which defines a redundant current window variable and asserts that it matches __glutCurrentWindow. Apply this patch to Mesa/src/glut/glx/glut_win.c, recompile and try your app again. diff -u -r1.6 glut_win.c --- glut_win.c 12 Feb 2003 23:56:23 -0000 1.6 +++ glut_win.c 8 Feb 2005 01:21:07 -0000 @@ -129,10 +129,13 @@ return NULL; } +static GLUTwindow *__glutCurrentWindowBackup = NULL; + /* CENTRY */ int GLUTAPIENTRY glutGetWindow(void) { + assert(__glutCurrentWindow == __glutCurrentWindowBackup); if (__glutCurrentWindow) { return __glutCurrentWindow->num + 1; } else { @@ -153,6 +156,7 @@ "already bound" case, GLUT avoids the temptation to do so too. */ __glutCurrentWindow = window; + __glutCurrentWindowBackup = window; MAKE_CURRENT_LAYER(__glutCurrentWindow); @@ -803,6 +807,7 @@ if (window == __glutCurrentWindow) { UNMAKE_CURRENT(); __glutCurrentWindow = NULL; + __glutCurrentWindowBackup = NULL; } /* Begin tearing down window itself. */ if (window->overlay) {
No errors now.
Unless that patch was designed to learn more about the problem. I can't figure out what it is supposed to do. Was I supposed to close this bug?
My patch wasn't intended to fix the problem, but to help isolate it. At this point, my best guess is that either the PUI toolkit or your application is doing a stray memory write that just happens to sometimes hit the __glutCurrentWindow pointer. The fact that GLUT works fine without PUI and/or your application is a strong indicator. Is the Atlas program open source? Maybe I could try it.
Both Atlas and FlightGear are open source. Primary link is: http://atlas.sourceforge.net/ Dependencies are listed at the System Requirements link
Are you still able to reproduce this bug with the version of GLUT in Mesa?
I guess not. Everything has been updated since then.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.