Windowed mode system hardlock bug

[unimatrix]

I've just had Spring hardlock my computer (minutes after it suddenly jumped into windowed mode for no reason whatsoever). Even when I ssh'd into it and killed spring I still had to reboot, because the keyboard and mouse weren't responding.

I found this bug report that was supposedly "fixed"
http://springrts.com/mantis/bug_view_ad ... bug_id=862

Could you please reopen it, because it clearly hasn't been fixed.

My system is similar to that of the person who reported the bug:
Ubuntu 9.10 Karmic (x86_64)
Latest Fglrx ATI driver on Radeon 4870

[hoijui]

with certainty of 95+%, this is a bug in fglrx.
i get the same with fglrx.. it is known to be very buggy for many cards, and problems with it get worse the newer the rest of your system is (xorg eg).
in other words... we can not fix it.

[unimatrix]

OK so I guess I'm done with Spring then since I cannot play it.

I wonder why even though I agree that fglrx is buggy as hell, this doesn't happen in any other game.

[Satirik]

OK so I guess I'm done with Spring then since I cannot play it.

I wonder why even though I agree that fglrx is buggy as hell, this doesn't happen in any other game.

you look angry, it seems like your comp/drivers/os/everything is perfect but spring is so fuckin buggy ... why the fuck did you even install such a crappy peace of awful game on such an awesome comp ?

[unimatrix]

Good point, I don't know what came over me.
And to think I even promoted the game to everyone I know! Damn, I must be possessed by an evil daemon or something.

[Tobi]

Post a stacktrace (i.e. install debug package, run in gdb, press ctrl+c when it hangs, then type 'thread apply all bt'. Put all the output in a file and attach to the report.)

We can not do anything with the bug report as it is.

EDIT: If PC locks up hard try to ssh into it from another machine to get a stacktrace. If ssh doesn't work anymore (be sure to install ssh beforehand) then it definitely isn't a Spring bug.

[BrainDamage]

I wonder why even though I agree that fglrx is buggy as hell, this doesn't happen in any other game.

there are couple hundred opengl functions, and opengl itself is a state-based system ( orders of calling the commands affects heavily the result, not just the params ), if the bug shows only with certain combinations, the low probability to reproduce explains why not other games are affected ( diff functions used, diff calling order, etc )

[Satirik]

Good point, I don't know what came over me.
And to think I even promoted the game to everyone I know! Damn, I must be possessed by an evil daemon or something.

that's your training for spring, you're already ragequiting, for once it's not because of regret !

[unimatrix]

Post a stacktrace (i.e. install debug package, run in gdb, press ctrl+c when it hangs, then type 'thread apply all bt'. Put all the output in a file and attach to the report.)

We can not do anything with the bug report as it is.

EDIT: If PC locks up hard try to ssh into it from another machine to get a stacktrace. If ssh doesn't work anymore (be sure to install ssh beforehand) then it definitely isn't a Spring bug.

Finally a decent answer (was getting the feeling this forum is full of trolls).

Anyway, I'm not too keen on hard resetting my computer, but since ssh worked last time I can probably reboot it from there (hopefully).
Would it be too much to ask for a -dbg version to be put in the PPA repository?

there are couple hundred opengl functions, and opengl itself is a state-based system ( orders of calling the commands affects heavily the result, not just the params ), if the bug shows only with certain combinations, the low probability to reproduce explains why not other games are affected ( diff functions used, diff calling order, etc )

Yeah that's probably it. But let's be real: we know ATI isn't going to do anything about it any time soon. Still, at least you guys could reopen that bug to acknowledge that it exists.

[hoijui]

it is X that is hard locking, you don't even have to restart really.. even doh it makes little difference, as you lost all open windows and stuff anyway.

[unimatrix]

it is X that is hard locking, you don't even have to restart really.. even doh it makes little difference, as you lost all open windows and stuff anyway.

It was X first, then I switched to framebuffer. I could log in, but then it froze there too before I could kill spring (I wasn't in a hurry, because I didn't think this would happen). So no, It's not just X.

[imbaczek]

if you had a hard lock such that even the magic sysrq didn't work (don't know if you tried it), it's definitely not spring's fault.

[BrainDamage]

if you had a hard lock such that even the magic sysrq didn't work (don't know if you tried it), it's definitely not spring's fault.

magic sysrq fails only in the case of a kernel panic, since he said he could ssh into the box, I'd assume the kernel was in a more or less working condition ( if we exclude the video driver module )

[unimatrix]

if you had a hard lock such that even the magic sysrq didn't work (don't know if you tried it), it's definitely not spring's fault.

According to your bug tracker this issue has been resolved and should not happen. At least spare us the lie.

And no, Magic SysRq didn't fail. It's how I rebooted it.

[BrainDamage]

According to your bug tracker this issue has been resolved and should not happen. At least spare us the lie.

try to be less abrasive in your answers ...
you should be able to reopen the ticket yourself, just create an account there

[unimatrix]

According to your bug tracker this issue has been resolved and should not happen. At least spare us the lie.

try to be less abrasive in your answers ...
you should be able to reopen the ticket yourself, just create an account there

I tried that, but I can't reopen (no editing options). That's why I'm here.

[Forboding Angel]

You can create a new account and link a new bug to an old one.