I just did a fresh install today and everytime I tried setting the video resolution the game would crash.

Setting multithreaded=0 fixed the issue. I sent in a automated bug crash report.

Need anymore details, and I'll submit them via a ticket.

The latest update may have fixed this issue.

Still crashing for me too. Not when switching resolution but randomly.

Last time this was printed to the terminal:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
vendetta: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Segmentation fault (core dumped)

Single client and no plugins.
OSS ATI drivers.

Also.. is it normal that it says "Using 0 physics worker threads." in the log file?

Hm, i have not heard of XInitThreads. I'll have to look into that.

The 0 physics worker threads message is fine. You can change that number by adding:
oethreads=4
to create 4 worker threads.
I don't recommend too many threads because of diminishing returns.
Also, do that at your own risk!

- Ray

No issues here w/multithreading turned on.

Edit: scratch that, see below.

I'll try enabling it again tonight and see if there are still issues.

Ray, I just had mine crash with an XCB assertion too. Got a core dump file. Want it?

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
vendetta: xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
zsh: segmentation fault (core dumped) bin/vendetta

5 times sunday for me. Variations of this error and a few others. Most were sent through the bug reporter that loads up upon crash, but at least one of the crashes didn't even trigger that. Almost all of the time this occurs when bringing up the nav/info screen from regular flight view.

abortretryfail, yeah, or at least the backtrace of it.

arf and cellsafemode, try out this binary:
http://www.ratelis.com/vo64.gz
It calls XInitThreads() on startup.
Place it into your .vendetta directory and run that instead of the vendetta updater.

I'll be able to try it in about 2 hours when I get home (for some odd reason my work blocks the updater ports so VO can't be run. Bastards).

Lasted through a small border skirmish ok with that vo64 binary, but it seems to run a little slower... maybe a 20% hit to framerate?

This netbook isn't very fast though, that could be a lot of things.

I followed your instructions but even with the regular ~/.vendetta/vendetta binary, directly executing it rather than the updater first yields this error:

Fatal Error: Couldn't open window.

running the updater works as expected but since it overwrites the replaced binary, testing would be impossible that way.

cd ~/.vendetta/ to fix that

You also don't need to replace the vendetta binary, just put vo64 there and chmod it +x

Some heavy debugging must be enabled as I'm apparently limited to around 75fps... But that avg is not stable. In any case I'll try to reproduce the crash but I'll be staying out of fights with this binary. Way too slow for my taste

edit: I just spent the last hour doing nearly nothing but entering and exiting a dock and opening and closing the nav menu as much as possible while out in space. No crashing. I can't say that means success since it happened 5 times over the course of around 16 hours. But if this slowdown isn't caused by debugging code being enabled. then the cure is worse than the disease.

Hm, it has no additional debugging info. So enabling X threads apparently is a large speed hit.
Thanks for trying it out so far.

It enables a bunch of locking in Xlib, which can slow stuff down. It didn't crash, but that sorta defeats the purpose of multi-threaded rendering.

So it looks like the problem is either a missed lock issue or a race with VO's lock implementation

Ray, did you get my link to the core dump?

Yes, thanks.
And I think I found the place where the game thread was accidentally calling into Xlib. I'll be posting another test binary for you to try. I will also remove the XInitThreads() call.