Crash on boot (Linux/Wine)

[OxOOO5cO77]

Hi -

Up until recently, I had Drox Operative working a-ok on my Linux machine under wine. It had been a while since I had a chance to play, so I patched it to the latest stable. (I don't remember which version I was on previous -- it would've been at least 6 months ago, though.)

Now when I run, the main menu flashes briefly and Wine segfaults. The best debugging I could do (via wine output) indicated that there was a memory stomp occurring; but those messages only seem to rarely occur -- most of the time it's straight back to bash prompt.

The last message I manage to capture:

malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed.

(20+ successive runs did not yield any message)

Anyways, if there's anything I can do to assist, please let me know. I'd be happy do whatever it takes to get back to playing this great game.

-scott

[Shadow]

Which version are you using? If it is 1.013 or newer it could be the joystick support. If that is so, you can open you user.cfg and change i_joystickEnabled to 0 and it might fix the problem.

If you change logfile to 2 in your user.cfg, then the log.txt file that the game generates might be useful to see how far it is getting before crashing.

I don't know where user.cfg or log.txt is going to end up on a linux box. In Vista or later in Windows land, it would be in C:\Users\YOUR USER NAME\AppData\Local\DroxOperative\User

[OxOOO5cO77]

Grabbed the latest Beta patch, made the above changes to my user.cfg, and ended up with:

Safe and dependant systems initialized
Database parsed
Graphics system initialized
Opened OpenAL Soft Device
Using 256 sound sources
Sound system initialized
Input initialized
Debug system started

One out of 5 runs netted this before segfaulting:

*** glibc detected *** DroxOperative.exe: malloc(): memory corruption (fast): 0x7cfc4088 ***

Way to be ambiguous, glibc.

Thanks again,
-scott

[OxOOO5cO77]

So I decided to not stop at disabling the joystick...and discovered that setting s_initSound to 0, while obviously providing a more quiet experience, allows the game to at least run.

Also, setting developer to 1 provided a slightly more verbose log.txt, but appart from enumerating my CPU features (and my sound card as "Out: default") nothing terribly interesting additional is in there...

Hope that helps,
-scott

[Shadow]

That's strange. The next line you should be seeing is "Done initializing". There is only a few things between "Debug system started" and "Done initializing" and none of them have anything to do with the sound system (unless there is a deeply buried sound call somewhere).