Opened 10 years ago
Closed 9 years ago
#47303 closed defect (duplicate)
SIGSEGV in glx_display_free
Reported by: | RJVB (René Bertin) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | ||
Port: | mesa |
Description
Trying to use port:glxinfo on the X server running on my KUbuntu 14.04.2 LTS system, I get the following:
%> env DISPLAY=patux.local:0.0 glxinfo name of display: patux.local:0.0 Error: couldn't find RGB GLX visual or fbconfig Error: couldn't find RGB GLX visual or fbconfig Segmentation fault Exit 139
Process: glxinfo [83427] Path: /opt/local/bin/glxinfo Identifier: glxinfo Version: 0 Code Type: X86-64 (Native) Parent Process: tcsh [95443] Responsible: Terminal [448] User ID: 505 Date/Time: 2015-03-29 15:14:48.521 +0200 OS Version: Mac OS X 10.9.5 (13F34) Report Version: 11 Anonymous UUID: 64B814D9-356F-6F85-8341-E17C1354A330 Sleep/Wake UUID: 3ED5D38F-1899-4189-AEEE-E2781F354C9B Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010 VM Regions Near 0x10: --> __TEXT 000000010b8c4000-000000010b8ca000 [ 24K] r-x/rwx SM=COW /Volumes/VOLUME/* Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libGL.1.dylib 0x000000010b8d7897 glx_display_free + 14 1 libGL.1.dylib 0x000000010b8d77cc __glXCloseDisplay + 111 2 libX11.6.dylib 0x000000010b9698da XCloseDisplay + 156 3 glxinfo 0x000000010b8c670c main + 2667 4 libdyld.dylib 0x00007fff9158f5fd start + 1
mesa is @10.4.4_2 . Doing this from my 10.6 VM glxinfo just exits, without crashing. And that's of course the correct thing to do.
Change History (5)
comment:1 Changed 10 years ago by RJVB (René Bertin)
comment:2 Changed 10 years ago by mf2k (Frank Schima)
Cc: | jeremyhu@… removed |
---|---|
Owner: | changed from macports-tickets@… to jeremyhu@… |
comment:3 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
yes, we don't support IGLX. Certainly, there is a bug there in that it should err rather than crash, but that won't really address your concern.
comment:4 Changed 10 years ago by RJVB (René Bertin)
Actually, fixing the crash with a proper error is my main concern. The CrashReporter can take a lot of time when it kicks in (during which your commandline is frozen, if that's how you launched the crashed app).
comment:5 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
xdpyinfo reports the following on the remote server:
(etc)