Skip to content
This repository has been archived by the owner on Apr 17, 2022. It is now read-only.

Glew 1.9 is unstable / broken with QuesoGLC #3679

Closed
wzdev-ci opened this issue Aug 23, 2012 · 38 comments
Closed

Glew 1.9 is unstable / broken with QuesoGLC #3679

wzdev-ci opened this issue Aug 23, 2012 · 38 comments
Labels
closed component: other normal
Milestone
unspecified

Comments

@wzdev-ci
Copy link
Contributor

resolution_fixed type_bug | by manschwetus@...

I suspect first the new nvidia-drivers 304.37, afaik 302.17 was fine (90% sure). I also updated from kernel 3.4.4 to 3.5.2. For further information just ask.


(gdb) bt full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x00000000006698de in __glcSaveGLState ()
No symbol table info available.
#2  0x000000000066eb0a in __glcRenderCountedString ()
No symbol table info available.
#3  0x00000000006700b3 in glcRenderString ()
No symbol table info available.
#4  0x0000000000646423 in iV_DrawTextRotated (
    string=0x1055b20 <version_getFormattedVersionString()::versionString> "Version SDL-branch-3.1 branch 444a7af - Built Aug 23 2012 - DEBUG", XPos=<optimized out>, YPos=<optimized out>, rotation=90)
    at textdraw.cpp:624
        matrix_mode = 5888
        __FUNCTION__ = "iV_DrawTextRotated"
#5  0x00000000004b77c9 in displayTitleBitmap (psWidget=<optimized out>, xOffset=<optimized out>, 
    yOffset=<optimized out>, pColours=<optimized out>) at frontend.cpp:1475
        modListText = '\000' <repeats 255 times>
#6  0x0000000000600ceb in widgDisplayForm (psForm=0x19dc3d0, xOffset=0, yOffset=0)
    at widget.cpp:1496
        psCurr = 0x0
        xOrigin = 0
        yOrigin = 0
#7  0x0000000000600d65 in widgDisplayForm (psForm=0x1a27090, xOffset=0, yOffset=0)
    at widget.cpp:1528
        psCurr = 0x19dc3d0
        xOrigin = 0
        yOrigin = 0
#8  0x00000000006030d0 in widgDisplayScreen (psScreen=<optimized out>) at widget.cpp:1546
No locals.
#9  0x00000000004baa2c in runTitleMenu () at frontend.cpp:172
        id = <optimized out>
#10 0x00000000005f8865 in titleLoop () at wrappers.cpp:183
---Type <return> to continue, or q <return> to quit---
        RetCode = TITLECODE_CONTINUE
        __FUNCTION__ = "titleLoop"
#11 0x00000000005150ad in runTitleLoop () at main.cpp:924
No locals.
#12 mainLoop () at main.cpp:996
No locals.
#13 0x00000000006758d5 in wzMain3 () at main_sdl.cpp:1257
        event # {type 4 '\004', active # {type 4 '\004', gain # 0 '\000', state 0 '\000'}, 
          key # {type 4 '\004', which # 0 '\000', state 0 '\000', keysym # {scancode 63 '?', 
              sym # 1, mod KMOD_NONE, unicode # 0], motion {type = 4 '\004', 
            which # 0 '\000', state 0 '\000', x # 1087, y 797, xrel # 1, yrel 0}, button = {
            type # 4 '\004', which 0 '\000', button # 0 '\000', state 0 '\000', x = 1087, 
            y # 797}, jaxis {type # 4 '\004', which 0 '\000', axis # 0 '\000', value 1087}, 
          jball # {type 4 '\004', which # 0 '\000', ball 0 '\000', xrel # 1087, yrel 797}, 
          jhat # {type 4 '\004', which # 0 '\000', hat 0 '\000', value # 0 '\000'}, jbutton {
            type # 4 '\004', which 0 '\000', button # 0 '\000', state 0 '\000'}, resize = {
            type # 4 '\004', w 52233279, h # 1}, expose {type # 4 '\004'}, quit {
            type # 4 '\004'}, user {type # 4 '\004', code 52233279, data1 # 0x1, data2 0x0}, 
          syswm # {type 4 '\004', msg = 0x1]
#14 0x0000000000515b50 in realmain (argc=1, argv=<optimized out>) at main.cpp:1327
        utfargv = <optimized out>
        __FUNCTION__ = "realmain"
        engine # {<QAbstractFileEngineHandler> {<No data fields>}, <No data fields>}
        w = 1920
        buf = "Using language: Systemsprache\000)\000\340\240F\001\000\000\000\000\001\000\000\000\000\000\000\000\310\361\222", '\000' <repeats 13 times>, "\030\322\377\377\377\177\000\000(\322\377\377\377\177\000\000\000\000\000\000\000\000\000\000\341\207\336\367\377\177\000\000\001", '\000' <repeats 15 times>, "(\322\377\377\377\177\000\000P\nq\367\377\177\000\000@\240F\001\000\000\000\000\036\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\210\000\000\000\000\000\001\000\000\000\000\000\000\000\305\360\336\367\377\177\000\000\000\000\000\000\000\000\000\000\340b\222\367\377\177\000\000\004", '\000' <repeats 15 times>"\270, \201F\001\000\000\000\000@\000\000\000\000\000\000\000\036\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\210\000\000\000\000\000\300'F\000\000\0---Type <return> to continue, or q <return> to quit---
00\000"
        utfargc = 1
        h = <optimized out>
#15 0x00007ffff412f4bd in __libc_start_main () from /lib64/libc.so.6
No symbol table info available.
#16 0x0000000000463085 in _start ()
No symbol table info available.

Issue migrated from trac:3679 at 2022-04-16 10:35:02 -0700
@wzdev-ci
Copy link
Contributor Author

vexed changed status from new to closed

@wzdev-ci
Copy link
Contributor Author

vexed changed resolution from `` to external

@wzdev-ci
Copy link
Contributor Author

vexed commented

This isn't a warzone issue that we have control of.
Looks like video driver problem, or perhaps a problem with quesoGLC and your system.

Nothing we can do to fix this I don't believe. (As in, it works for most every other system)

Closing as external issue.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

Hm if it is really an issue introduce by latest nvidia drivers on quadro fx 880M like systems it, may become more often. I rebuild queso with debug information, but haven't got a more informative back trace. Maybe someone with a bit more solid background in this matter could tell me what could be wrong here.

@wzdev-ci
Copy link
Contributor Author

vexed commented

Can you try the "free" nvidia open source drivers, and see if that works for you ?

That would be another way to narrow down the problem, but I never used those drivers before, so no idea if they are stable or not.

@wzdev-ci
Copy link
Contributor Author

Kittykatt uploaded file warzone2100.gdmp-qaGaMF (80.3 KiB)

segfault log

@wzdev-ci
Copy link
Contributor Author

Kittykatt commented

We've reproduced a segmentation fault on 3.5.2 kernel with propietary nvidia drivers on latest 3.1. The segmentation fault occurred simultaneously on all three human players' systems. Attaching bug report.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

I found two other users having same issue.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... uploaded file user1.gdmp (12.8 KiB)

gdmp of first user

@wzdev-ci
Copy link
Contributor Author

manschwetus@... uploaded file user2.gdmp (1.7 KiB)

gdmp of second user

@wzdev-ci
Copy link
Contributor Author

Kittykatt commented

Can I ask what distribution of Linux you and those users are using? We're all running Arch Linux here.

@wzdev-ci
Copy link
Contributor Author

wzdev-ci commented Aug 25, 2012 •
edited

vexed commented

Replying to Warzone2100/old-trac-import#3679 (comment:4):

We've reproduced a segmentation fault on 3.5.2 kernel with propietary nvidia drivers on latest 3.1. The segmentation fault occurred simultaneously on all three human players' systems. Attaching bug report.

Your bug has nothing to do with video drivers, that is the path finding bug...

@wzdev-ci
Copy link
Contributor Author

vexed commented

user1.gdmp shows external crash (video drivers it seems)

user2.gdmp is useless, gdb isn't installed, so no info in that one.

I still think you should give the OS nvidia drivers a try (not the binary blobs), and see if that helps.

@wzdev-ci
Copy link
Contributor Author

anonymous commented

I'll try that, but we already tried to downgrade nvidia-drivers to a version previously working fine for me. Would be great if someone could tell us to which libs the #3 to #0 entries of my backtrace should belong, so we could try to provide debug information for gdb.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... changed status from closed to reopened

@wzdev-ci
Copy link
Contributor Author

manschwetus@... changed resolution from external to ``

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

ok, I tried now with my second notebook (T60) it is a x86 linux with gallium / mesa / kms

Looks like same issue.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... uploaded file warzone2100.gdmp-GfQ07j (13.3 KiB)

warzone crash dump from my T60

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

Additionally downgrading nvidia-drivers to a known good dosn't solve this on my primary system

@wzdev-ci
Copy link
Contributor Author

vexed changed status from reopened to closed

@wzdev-ci
Copy link
Contributor Author

vexed changed resolution from `` to external

@wzdev-ci
Copy link
Contributor Author

wzdev-ci commented Aug 26, 2012 •
edited

vexed commented

Replying to Warzone2100/old-trac-import#3679 (comment:11):

Additionally downgrading nvidia-drivers to a known good dosn't solve this on my primary system

Downgrading to a known good driver ? How did you come to that conclusion, based on what ?
Have you tried nouveau yet ?

There isn't anything we can do with these crash dumps, they all fall outside the scope of our source, and are in the area of external libs.

Unless you want to roll back your system to pre-system update, then start to update libs one by one to find which one is at fault, or you enable debugging symbols on everything available (though, that is impossible with nvidia's binary blob) about all you can do is keep trying different libs, and hopefully you will find some working ones.

Heck, you might even try another distro, fedora, or debian, and give that a shot and see what happens.

Closing ticket again, as there is nothing we can do on our end to help facilitate your issues.

@wzdev-ci
Copy link
Contributor Author

vexed commented

Note, I suppose it could also be kernel related.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... uploaded file warzone2100.gdmp-vHw80f (26.1 KiB)

now my warzone also creates dump files, so here it is with as much debug symbols I was able to generate

@wzdev-ci
Copy link
Contributor Author

manschwetus@... changed status from closed to reopened

@wzdev-ci
Copy link
Contributor Author

manschwetus@... changed resolution from external to ``

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

Looks like warzone-3.1 is incompatible with glew-1.9 => problem occurs when warzone is build against glew-1.9, after downgrade of glew to 1.8 and rebuild of warzone it starts again. Thx to "josef64" at #gentoo.de, who found this out. He mentioned this thread http://forums.pcsx2.net/Thread-Linux-GSdx-plugin-on-Ati-card?page=5

@wzdev-ci
Copy link
Contributor Author

vexed changed status from reopened to closed

@wzdev-ci
Copy link
Contributor Author

vexed changed resolution from `` to external

@wzdev-ci
Copy link
Contributor Author

vexed changed title from Crash on startup after system update to Glew 1.9 is unstable / broken with QuesoGLC

@wzdev-ci
Copy link
Contributor Author

vexed commented

Nice that you found the problem library.
Unfortunately, we are not in charge of that lib, and you need to report the problem, upstream to the Glew chaps, in their bug tracker http://sourceforge.net/tracker/?group_id=67586 if it isn't already reported. Then again, it could be a issue with quesoGLC.

This still is a external issue though.

I'll leave it open for now, in case someone wants to write a check for glew 1.9 for autohell.

@wzdev-ci
Copy link
Contributor Author

vexed changed status from closed to reopened

@wzdev-ci
Copy link
Contributor Author

vexed changed resolution from external to ``

@wzdev-ci
Copy link
Contributor Author

vexed commented

Hit the wrong button.

@wzdev-ci
Copy link
Contributor Author

manschwetus@... commented

hm think you are right maybe this is the root cause of this http://sourceforge.net/tracker/?func=detail&aid=3449999&group_id=53918&atid=472059
Anyway there is a great chance that queso will become a problem in general as it is unmaintained over years now, years which brought a lot of change into linux 3D rendering. So my guess is that it must become a pita sooner or later.

@wzdev-ci
Copy link
Contributor Author

vexed changed status from reopened to closed

@wzdev-ci
Copy link
Contributor Author

vexed changed resolution from `` to fixed

@wzdev-ci
Copy link
Contributor Author

vexed commented

This should be fixed in the repo (master & 3.1).
The GLEW hacks we had were removed, and I can't replicate with the latest GLEW version.

If this is not the case, then please open a new ticket, and provide as much information as possible for us to be able to reproduce the issue.

Thanks for the report.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
closed component: other normal
Projects
None yet
Milestone
unspecified
Development

No branches or pull requests
1 participant
@wzdev-ci