Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segfault during window test with tiling window manager (i3) #8

Open
WillForan opened this issue Apr 9, 2022 · 10 comments
Open

segfault during window test with tiling window manager (i3) #8

WillForan opened this issue Apr 9, 2022 · 10 comments

Comments

@WillForan
Copy link

Under Xorg+i3, the test segfaults.
Using Xepher (no window manager or w/fluxbox), there is no issue!

that is:

Xephyr -br -ac -screen 800x600 :1 & xpy_pid=$!
DISPLAY=:1 cpanp t OpenGL::GLUT
# Module 'OpenGL::GLUT' tested successfully

but when the test window is resized by i3 (or I think that's the issue), I get a segfault

cpanp t OpenGL::GLUT
# same for `make test` cloned from master

Found FreeGLUT v30000
...
Using POGL v0.70
OpenGL installation: 4.6.0 NVIDIA 510.54
NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
...
Setting window close to trigger return from mainloop (freeglut).
Entering glutMainLoop
make: *** [Makefile:1085: test_dynamic] Segmentation fault (core dumped)

Not sure there is anything OpenGl::GLUT could/should do about this (set something like _NET_WM_WINDOW_TYPE_DIALOG ?), but thought it was worth documenting.

@mohawk2
Copy link
Contributor

mohawk2 commented Apr 10, 2022

Thanks for the report!

Segfaults are considered bad (m'kay), and I'd anticipate this is easily remedied (possibly just by a Perl croak rather than continuing to segfault). Could you try first compiling/installing your OpenGL::GLUT with -g (most easily by editing the Makefile to change OPTIMIZE to include a -g), running this again inside gdb in a way that crashes, possibly like this:

# clone this repo
perl Makefile.PL
# edit the Makefile as mentioned
make && gdb perl -ex 'run -Mblib t/01_use.t'
# inside gdb after it crashes:
bt

and sharing results?

@WillForan
Copy link
Author

WillForan commented Apr 12, 2022

huh! no error with running the t/* files or prove. But there's something special in test.pl (same segfault in make test make test_static and make test_dynamic)

[also, way out of my domain w/gdb. I tried to get something for the initial report but didn't know the perl -x trick or that bt gets to the useful stuff. Thanks for those pointers!]

# added -g, reran Makefile.PL and make
git diff
 -  'OPTIMIZE'   => $OPTS,
 +  'OPTIMIZE'   => "-g $OPTS",

# but no error running test by itself
gdb perl -ex 'run -Mblib t/01_use.t'
 1..1
 ok 1 - use OpenGL::GLUT;
 [Inferior 1 (process 496090) exited normally]
 (gdb) bt
 No stack.

prove
t/00_require.t .. ok   
t/01_use.t ...... ok   
All tests successful.
Files=2, Tests=2,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.09 cusr  0.01 csys =  0.12 CPU)
Result: PASS


## I can get the segfault using test.pl though
gdb perl -ex 'run -Mblib test.pl'

rogram received signal SIGSEGV, Segmentation fault.
0x00000000400b0ed4 in ?? ()
(gdb) bt

#0  0x00000000400b0ed4 in ?? ()
#1  0x00007ffff4de2fa9 in ?? () from /usr/lib/libnvidia-glcore.so.510.54
#2  0x00007ffff4df3c45 in ?? () from /usr/lib/libnvidia-glcore.so.510.54
#3  0x00007ffff4df46c7 in ?? () from /usr/lib/libnvidia-glcore.so.510.54
#4  0x00007ffff4a59fce in ?? () from /usr/lib/libnvidia-glcore.so.510.54
#5  0x00007ffff7e0c15b in fghDrawGeometryWire () from /usr/lib/libglut.so.3
#6  0x00007ffff7e13863 in glutWireTeapot () from /usr/lib/libglut.so.3
#7  0x00005555555b12f4 in XS_OpenGL__GLUT_glutWireTeapot (cv=0x555555d74090) at GLUT.c:2641
#8  0x00005555556730ac in Perl_pp_entersub ()
#9  0x0000555555669d03 in Perl_runops_standard ()
#10 0x00005555556a59cc in S_docatch ()
#11 0x0000555555669d03 in Perl_runops_standard ()
#12 0x00005555555da933 in Perl_call_sv ()
#13 0x00005555555a30f6 in generic_glut_Display_handler () at /home/foranw/src/utils/perl-cpan/OpenGL-GLUT/GLUT.xs:309
#14 0x00007ffff7e0e8e3 in fghRedrawWindow () from /usr/lib/libglut.so.3
#15 0x00007ffff7e1956b in ?? () from /usr/lib/libglut.so.3
#16 0x00007ffff7e18ad1 in fgEnumWindows () from /usr/lib/libglut.so.3
#17 0x00007ffff7e18d99 in glutMainLoopEvent () from /usr/lib/libglut.so.3
#18 0x00007ffff7e18e40 in glutMainLoop () from /usr/lib/libglut.so.3
#19 0x00005555555a78a0 in XS_OpenGL__GLUT_glutMainLoop (cv=0x555555d72660) at GLUT.c:833
#20 0x00005555556730ac in Perl_pp_entersub ()
#21 0x0000555555669d03 in Perl_runops_standard ()
#22 0x00005555555e1ea7 in perl_run ()
#23 0x00005555555b90ec in main (argc=3, argv=0x7fffffffdbb8, env=0x7fffffffdbd8) at perlmain.c:110

@WillForan
Copy link
Author

WillForan commented Apr 12, 2022

told i3 to float the window. that didn't help. so something about how WIMP managers handle the window that i3 isn't?

perl-opengl-glut-test-crash.mp4

@mohawk2
Copy link
Contributor

mohawk2 commented Apr 13, 2022

I suspect this may be caused by some clash between OpenGL::GLUT and main OpenGL. The test.pl I just copied across from main Perl OpenGL, and I may have made mistakes. All those "redefined" messages in your video clip are a bit surprising. Can you confirm what version of Perl OpenGL you have, and what version of the C glut and OpenGL libraries you have?

Also, does everything else appear to work apart from the test.pl?

@WillForan
Copy link
Author

I installed despite the test and haven't noticed anything crash. I only grabbed OpenGL::GLUT as a PDL dependency. And so far have only run matrix operations and PGPLOT

Not sure if this gets at the useful version numbers:

 cpan info OpenGL
OpenGL is up to date (0.70).

 which perl
/home/foranw/perl5/perlbrew/perls/perl-5.34.1/bin/perl

 pacman -Qi freeglut|grep Ver
#  /usr/lib/libglut.so.3.11.1

 pacman -Qi  libglvnd|grep Ver
Version         : 1.4.0-1
# /usr/lib/libGL.so.1.7.0

same environment, but no errors with no windows manager:

Xepher_perl-glut.mp4

@mohawk2
Copy link
Contributor

mohawk2 commented Apr 15, 2022

Thank you for the further information. Could I ask you to try the OpenGL test.pl, and see if that crashes as well?

@WillForan
Copy link
Author

crashes there too! Sorry I raised the issue here. seems to be upstream?

git clone git://pogl.git.sourceforge.net/gitroot/pogl/pogl


Program received signal SIGSEGV, Segmentation fault.
0x00000000400b0ed4 in ?? ()
(gdb) bt
#0  0x00000000400b0ed4 in ?? ()
#1  0x00007ffff4de3009 in ?? () from /usr/lib/libnvidia-glcore.so.510.60.02
#2  0x00007ffff4df3ca5 in ?? () from /usr/lib/libnvidia-glcore.so.510.60.02
#3  0x00007ffff4df4727 in ?? () from /usr/lib/libnvidia-glcore.so.510.60.02
#4  0x00007ffff4a5a02e in ?? () from /usr/lib/libnvidia-glcore.so.510.60.02
#5  0x00007ffff74e615b in fghDrawGeometryWire () from /usr/lib/libglut.so.3
#6  0x00007ffff74ed863 in glutWireTeapot () from /usr/lib/libglut.so.3
#7  0x00007ffff76b487b in XS_OpenGL_glutWireTeapot ()
   from /home/foranw/perl5/perlbrew/perls/perl-5.34.1/lib/site_perl/5.34.1/x86_64-linux/auto/OpenGL/OpenGL.so
#8  0x000055555565a33c in Perl_pp_entersub ()
#9  0x0000555555650f93 in Perl_runops_standard ()
#10 0x000055555568cc5c in S_docatch ()
#11 0x0000555555650f93 in Perl_runops_standard ()
#12 0x00005555555c1bc3 in Perl_call_sv ()
#13 0x00007ffff74e88e3 in fghRedrawWindow () from /usr/lib/libglut.so.3
#14 0x00007ffff74f356b in ?? () from /usr/lib/libglut.so.3
#15 0x00007ffff74f2ad1 in fgEnumWindows () from /usr/lib/libglut.so.3
#16 0x00007ffff74f2d99 in glutMainLoopEvent () from /usr/lib/libglut.so.3
#17 0x00007ffff74f2e40 in glutMainLoop () from /usr/lib/libglut.so.3
#18 0x00007ffff76b8275 in XS_OpenGL_glutMainLoop ()
   from /home/foranw/perl5/perlbrew/perls/perl-5.34.1/lib/site_perl/5.34.1/x86_64-linux/auto/OpenGL/OpenGL.so
#19 0x000055555565a33c in Perl_pp_entersub ()
#20 0x0000555555650f93 in Perl_runops_standard ()
#21 0x00005555555c904c in perl_run ()
#22 0x00005555555a0322 in main ()

@mohawk2
Copy link
Contributor

mohawk2 commented Apr 15, 2022

It does look a lot like glutWireTeapot is crashing in that circumstance, under that window manager. Could I ask you to try the "Basic Program" in https://math.hws.edu/bridgeman/courses/324/s06/doc/opengl.html with glutWireTeapot and see if we can narrow it down, or else rule out the Perl module?

@WillForan
Copy link
Author

I was able to compile and run the teapot example with solid and glutWireTeapot(1). no segfaults! Also no problem using OpenGL::GLUT w/WireTeapot. I feel like I'm taking a bunch of your time to chase down an bug that might be limited to just my system. Other than an extra cpanm --notest to get PDL, this isn't getting in my way at all! (But also happy to head down the rabbit hole more if it's helpful! When I get more time, I'll work through test.pl in the perldl2 shell hunting for the segfault)

Another maybe not-so-strange wrinkle, I used ssh+x11 forwarding to run test.pl on the problematic desktop from a laptop with same OS/WM (arch/i3) but totally different graphics hardware and test.pl ran through without a segfault!

ssh -Y $desktop
diff -W80 -y <(glxinfo) <(DISPLAY=:0 glxinfo)|head 
name of display: localhost:11.0       | name of display: :0
display: localhost:11  screen: 0      | display: :0  screen: 0
direct rendering: Yes                   direct rendering: Yes
server glx vendor string: SGI         | server glx vendor string: NVIDIA Corp
server glx version string: 1.4          server glx version string: 1.4
server glx extensions:                  server glx extensions:
    GLX_ARB_create_context, GLX_ARB_c |     GLX_ARB_context_flush_control, GL
    GLX_ARB_create_context_profile, G |     GLX_ARB_create_context_no_error, 
    GLX_ARB_fbconfig_float, GLX_ARB_f |     GLX_ARB_create_context_robustness
                                      >     GLX_ARB_multisample, GLX_EXT_buff

@mohawk2
Copy link
Contributor

mohawk2 commented Apr 18, 2022

It does seem like an extremely localised fault. It also sounds like if you have a very simple non-crashing script, and more-complicated crashing one, you could keep (depending on your preference) either deleting stuff from the complicated one, or adding stuff to the simple one from the complicated one (I think the first would be less effort) until the crashing stops, and report here what makes the difference?

I really appreciate the assistance here! There's a certain irony that all this OpenGL 1 stuff is fairly obsolete and there are plans (PDLPorters/pdl#349) to update past them. However, those will likely take a while to come to pass, whereas solving this might highlight something valuable beyond this immediate point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants