New OpenBVE Build- Testers Please

OK, so to take your issues one by one:
1. Crashing/ funky control assignments: I've had to change the way the keyboard/ joystick assignments are stored. It shouldn't be crashing though.....
Fixing the crash, and sorting it out so that it resets the controls to default if an older controls.cfg file is detected are now on my list

2. Joystick not always detecting: Not sure- I can't reproduce this on Windows.
Not tested on Linux, as just at the moment, VMWare doesn't seem to like passing through joysticks- Will have to roll a physical box.

3. Joystick repeats broken: Again, I can't reproduce on Windows.
Testing as above.

4. 2D cabs crashing: Can't reproduce with your examples on Windows or Linux.
Which distro/ release variant please?
Any terminal output?

I suspect the 2D cabs issue is probably related to the joysticks problem; Can you try testing with it unplugged please?

Final note-
Rotation and state changes aren't currently implemented for scripting (Sorry....)
The same code will apply, I'd just prefer to get the kinks worked out using a single function first.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I've fixed several more bugs with this build, as follows:
* OpenAL properly cleans up after itself. (libtao does this automatically, but you seem to need to do it manually with OpenTK)
* No longer crashes when an invalid keyboard/ joystick key assignment is present.
* Doesn't attempt to poll a joystick which isn't connected.
* If a 1.4.3 key configuration is detected, it shows a nice error box, and resets them to default

http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440q.7z

(I'll have to redo the version numbering soon; A letter wasn't a good idea.....)

I also seem to have got VMWare to detect my joystick, but it isn't working in OpenBVE
I'll roll a physical box, but at this point, I could really do with knowing exactly what you're running, as there I have a known working (Well, at least semi-working) point of reference

Edit:
Phontanka, another thought-
Have you installed OpenAL on your two Windows boxes?
https://www.openal.org/downloads/

That wouldn't be installed by default, or by Windows updates.
Not sure what it'd do if it was missing, will try testing a little later.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Hi,

first of all, thanks for continuing the development!

Here's my configuration:
* Ubuntu 14.04 LTS (Trusty, 64-bit) with latest updates
* Mono JIT compiler version 3.2.8 (from package mono-runtime 3.2.8+dfsg-4ubuntu1.1)
* OpenAL 1.14 (from package libopenal1)
* hardware-wise nothing special - AMD FX-6100, 4 GB RAM, 240 GB SSD (where OpenBVE resides) + 2 TB HDD + NVidia GeForce 210 w/ 512 MB memory (GPU and memory max out at default display setting, so I need to dial down a bit - I ought to get a better graphics card)

Will try version q and see if anything's different.

Version q:
* attempting to either import a control file from 1.4.3 or overwrite the default one produces the following:

mono: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
AL lib: ReleaseALC: 1 device not closed

* sound has stopped working altogether (PulseAudio 4.0, the only enabled output at the moment is SoundBlaster E1 USB DAC) - it did work in version p

The joystick, Microsoft Sidewinder Precision Pro (the old one that came with a D connector to USB adapter) is a bit troublesome. I was able to get it recognized and displayed the first time after being plugged out and back in. This way I was able to assign joystick controls again. However, once the joystick disappears from the control view, I can no longer use it, and now I cannot get it to show up in version q no matter how many times I plug it back in. 

In version p, I can use the joystick, but it doesn't work correctly. I've set axis 2 to SINGLE_FULLAXIS, since the 323 has a combined brake and power handle. The power jumps from zero (centered) to full power, and the brake side doesn't work at all. Also, REVERSE_FULLAXIS, when assigned to an axis, moves the reverser forward, but not back.

When testing with jscal and jstest, the joystick works just fine. It also works fine in 1.4.3.

Oh, and the crash with 2D cabs still happens. Here's the terminal output:

Stacktrace:


Native stacktrace:

mono() [0x4b73d8]
mono() [0x50f13b]
mono() [0x423d22]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f6162b68340]
/usr/lib/nvidia-340/libGL.so.1(+0xd7c09) [0x7f6133d87c09]

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No threads.

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted (core dumped)

I can provide strace output if you want.

I though that the scripting would work on all the animation commands because you said:

leezer3 wrote:This build is another step, and fully implements the scripting with access to all standard OpenBVE variables

But I agree with making sure it works properly without issues before expanding to the other commands.

With "q" version on windows I get no sound at all. Jumping stations and driving along quite a distance does not bring the sound back. This happened when I used a NWM route. I also tried it on my WIP with no sound as well.

Hmm....
Something's funky somewhere, but you knew that already

This all smells very Nvidia driver related:
http://ubuntuforums.org/showthread.php?t=2073987
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/999191

Are you running Nouveau or the Nvidia proprietary lump?
Either way, please try updating if you can.

Would also like to know where it gets to in the loading process- Do the route/ train percentages complete & it dies after the final 'Loading Please Wait' message, or what exactly.
If necessary, I can start disabling things and see what happens, but unless I can get it to reproduce at this end, I'm shooting blindly.....

Controls.cfg problem-
Have you started the program as root/ with sudo at all recently?
It writes the controls.cfg out to disk every time it loads a route, which is probably a bad idea. I've added this to the list of things I need to change
If you've started as root/ using sudo, it's probably gone and changed the owner of the controls.cfg file to root....

Sound Not Working-
My fault entirely, was a side effect of fixing the OpenAL not being closed error I didn't notice.....
I've fixed that, and added detection/ a prompt to not run as the root user on Linux.
Haven't bumped the build version though.
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440q.7z

I though that the scripting would work on all the animation commands because you said.....

Must be clearer, sorry
There are still problems I'm sure I haven't thought of yet. I could really do with someone who knows C# trying to write a script and breaking it for me

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris, the q build will not start on my Windows 10 computer either.

Hi,

leezer3 wrote:Hmm....
Something's funky somewhere, but you knew that already 

This all smells very Nvidia driver related:
http://ubuntuforums.org/showthread.php?t=2073987
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/999191

Are you running Nouveau or the Nvidia proprietary lump?
Either way, please try updating if you can.

I'm using the proprietary drivers, and I've just updated. I checked that the latest driver is actually in use. Please note that the bug threads above are three years old.

Would also like to know where it gets to in the loading process- Do the route/ train percentages complete & it dies after the final 'Loading Please Wait' message, or what exactly.
If necessary, I can start disabling things and see what happens, but unless I can get it to reproduce at this end, I'm shooting blindly.....

The route gets completely loaded. The message comes up while loading the train. I can provide strace output, listing every system call the program makes until the crash, if you want it. Please note that it's 89 megabytes of text.

Controls.cfg problem-
Have you started the program as root/ with sudo at all recently?
It writes the controls.cfg out to disk every time it loads a route, which is probably a bad idea. I've added this to the list of things I need to change 
If you've started as root/ using sudo, it's probably gone and changed the owner of the controls.cfg file to root....

No, there's absolutely no need to run OpenBVE as root. The permissions of controls.cfg are correct.

Sound Not Working-
My fault entirely, was a side effect of fixing the OpenAL not being closed error I didn't notice.....
I've fixed that, and added detection/ a prompt to not run as the root user on Linux.
Haven't bumped the build version though.
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440q.7z

Downloaded, thank you. Reminding people not to run as root is nice, as it really should be unnecessary under normal circumstances.

Yeah, I know they're three years old (Those pair were the first couple of examples I found), but it's still rather suspect.
If I limit the search to the past year, I can find plenty more fingers pointing in the Nvidia driver direction, but I agree not 100% conclusive.
Something in somewhere in unmanaged kernel code is taking down OpenGL, and it's a case of figuring out what I'm doing that's causing it.
As it's working OK on ATI hardware and a couple of virtual machines, I need to try and reproduce it myself.

Having said that, I'm not the best person to be trying to read strace output unfortunately
Whilst I can interpret it up to a point, I don't think my understanding is good enough to catch this one.....

Controls.cfg
If the permissions on controls.cfg are fine, I can't explain this one at the minute.
This works perfectly on my Xubuntu and 15.10 VMs (Program stored in /home/Christopher/OpenBVE)

Hungarian Windows:
I'm at a loss
I've just installed a fresh copy of Hungarian Windows 7 SP2 in a VM, and the main menu loads perfectly with no Windows updates or anything.
Hungarian keyboard layout setup and everything.

Cheers

Chris Lees

http://www.bvecornwall/co.uk

OK, so whilst doing some testing on key repeats, I've just discovered a rather nasty bug (Somewhat of an oversight on my part....) whilst testing, which may explain the broken SDL2 behaviour.

I'm going to need to rewrite the way that the pause function & menu activation is handled, as it's fundamentally broken at the minute, and now looking at it, I'm surprised it worked at all under OpenTK......

Will try and sort this out tomorrow, and then we can see if SDL2 works any better for you jsiren

Cheers

Chris Lees

http://www.bvecornwall.co.uk

The sound works fine now with the newer version. I don't know C# but it would be nice if someone did know or you would not be only person working on the program or plugins!

The difficult part isn't so much C#, but reading and editing other people's code, in which Chris has been making a commendable job.

Editing isn't so bad, it's making it actually work that's the problem

At the moment, I haven't actually really done that much in terms of anything particularly interesting.
Whilst I've fixed quite a lot of pre-existing bugs, that's the easy part.


I've redone the way the pause menu is handled in this build, and I've also moved key handling to keyevents:
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440r.7z

Running a while loop whilst paused inside the OpenTK frame rendering function was *seriously* not a good idea.....
Xubuntu & 15.10 now work correctly with SDL2 installed without the previous hack, and I suspect that keyboard handling in general may well be a lot better.

jsiren-
If we're lucky, this may sort the crash you're seeing.
Not especially hopeful, but still.

This doesn't make my joystick work though, even though jstest sees it
I think I'm going to need to run up a test app independent from OpenBVE, and try some lower level debugging, as I'm not currently sure if VMWare is affecting things at all....

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris, OpenAL is installed on both of my computers. I tried removing OpenAL but it did not seem to make a difference. On the Windows 10 box I have .NET Framework 4.6 (that is at least what this page suggests: https://msdn.microsoft.com/en-us/library/hh925568%28v=vs.110%29.aspx ):



The r build will not run either, but the mouse cursor keeps circulating for a long time.

With "r" version strange things are happening. At times pressing a key results something else happening instead. This happened in the first 30 seconds after the route have loaded. For example F (forward direction) did Ctrl + B (brake info) and Z did the ESC Menu of quitting the program. But when this happens no key works and the program gets stuck. But I do get a message after a while of :"An error occurred whilst attempting to switch to fullscreen mode. Please check your fullscreen resolution settings." However I have only been running it in windowed mode and had not changed it from windowed mode.

The "r" version appears to not release the ctrl key when pressed and then released it still works as though the ctrl key is pressed. For example say you check the timetable using ctrl+t from then on just pressing t will turn it on or off, the same is true for all other ctrl modifiers.
It also appears as though the sound bug with NWM has come back, although it seams to correct itself much quicker than the last one.

Observations with version r:

* much smoother and more responsive than previous versions
* GPU usage is much better, I get a much better framerate with default settings than in 1.4.3
* I ran into the sticky Ctrl issue as well
* joystick buttons still repeat
* the loading problem still occurs with everything except the 323 - the crash happens most often at "loading train - 22.7%" or 22.8%, in the case of the DB Sprinter at 7.7%

I was able to produce a more complete stack trace from the crash:

~/OpenBVE_1440r$ mono OpenBve.exe
Could not set X locale modifiers
Stacktrace:


Native stacktrace:

mono() [0x4b73d8]
mono() [0x50f13b]
mono() [0x423d22]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fbd03b18340]
/usr/lib/nvidia-340/libGL.so.1(+0xd7c09) [0x7fbcf6847c09]

Debug info from gdb:

[New LWP 4358]
[New LWP 4357]
[New LWP 4356]
[New LWP 4354]
[New LWP 4351]
[New LWP 4350]
[New LWP 4349]
[New LWP 4348]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
  Id   Target Id         Frame 
  9    Thread 0x7fbd00d1f700 (LWP 4348) "mono" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  8    Thread 0x7fbcf72bf700 (LWP 4349) "SDLTimer" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  7    Thread 0x7fbced03f700 (LWP 4350) "dconf worker" 0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  6    Thread 0x7fbcec83e700 (LWP 4351) "gdbus" 0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  5    Thread 0x7fbce7317700 (LWP 4354) "gmain" 0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  4    Thread 0x7fbce4bd7700 (LWP 4356) "threaded-ml" 0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  3    Thread 0x7fbcd5ff7700 (LWP 4357) "mono" 0x00007fbd03b17b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7fbce5bd7700 (LWP 4358) "mono" 0x00007fbd03b17ee9 in __libc_waitpid (pid=pid@entry=4359, stat_loc=stat_loc@entry=0x7fbd045d719c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
* 1    Thread 0x7fbd046667c0 (LWP 4347) "mono" 0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81

Thread 9 (Thread 0x7fbd00d1f700 (LWP 4348)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x000000000062f667 in mono_sem_wait (sem=sem@entry=0x982440 , alertable=alertable@entry=1) at mono-semaphore.c:119
#2  0x00000000005aba15 in finalizer_thread (unused=unused@entry=0x0) at gc.c:1073
#3  0x000000000058e34b in start_wrapper_internal (data=0x13e1700) at threads.c:643
#4  start_wrapper (data=0x13e1700) at threads.c:688
#5  0x000000000062410d in thread_start_routine (args=args@entry=0x13643e8) at wthreads.c:294
#6  0x0000000000633ef5 in inner_start_thread (arg=0x13e15a0) at mono-threads-posix.c:49
#7  0x00007fbd03b10182 in start_thread (arg=0x7fbd00d1f700) at pthread_create.c:312
#8  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7fbcf72bf700 (LWP 4349)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007fbcfbbb952e in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#2  0x00007fbcfbbb9675 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#3  0x00007fbcfbb6eba1 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007fbcfbb6e73d in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007fbcfbbb9279 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6  0x00007fbd03b10182 in start_thread (arg=0x7fbcf72bf700) at pthread_create.c:312
#7  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7fbced03f700 (LWP 4350)):
#0  0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbcf2a40fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fbcf2a410ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fbced0471ad in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007fbcf2a65f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbd03b10182 in start_thread (arg=0x7fbced03f700) at pthread_create.c:312
#6  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7fbcec83e700 (LWP 4351)):
#0  0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbcf2a40fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fbcf2a4130a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fbceeb57336 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007fbcf2a65f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbd03b10182 in start_thread (arg=0x7fbcec83e700) at pthread_create.c:312
#6  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7fbce7317700 (LWP 4354)):
#0  0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbcf2a40fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fbcf2a410ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fbcf2a41129 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fbcf2a65f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fbd03b10182 in start_thread (arg=0x7fbce7317700) at pthread_create.c:312
#6  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fbce4bd7700 (LWP 4356)):
#0  0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbcfb3e0031 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x00007fbcfb3d183c in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x00007fbcfb3d1ece in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x00007fbcfb3d1f80 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x00007fbcfb3dffe3 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x00007fbcf9795f08 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so
#7  0x00007fbd03b10182 in start_thread (arg=0x7fbce4bd7700) at pthread_create.c:312
#8  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fbcd5ff7700 (LWP 4357)):
#0  0x00007fbd03b17b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbce5bff54a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#2  0x00007fbce5c0c5eb in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#3  0x00007fbce5bfee6a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#4  0x00007fbd03b10182 in start_thread (arg=0x7fbcd5ff7700) at pthread_create.c:312
#5  0x00007fbd0383a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fbce5bd7700 (LWP 4358)):
#0  0x00007fbd03b17ee9 in __libc_waitpid (pid=pid@entry=4359, stat_loc=stat_loc@entry=0x7fbd045d719c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x00000000004b7465 in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0x7fbd045d7ac0) at mini-exceptions.c:2299
#2  0x000000000050f13b in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7fbd045d7ac0, fault_addr=, stack_ovf=stack_ovf@entry=0) at exceptions-amd64.c:908
#3  0x0000000000423d22 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fbd045d7bf0, context=0x7fbd045d7ac0) at mini.c:6769
#4  
#5  0x00007fbcf6847c09 in glGenTextures () from /usr/lib/nvidia-340/libGL.so.1
#6  0x0000000041b70129 in ?? ()
#7  0x00007fbd025c0200 in ?? ()
#8  0x00007fbd02668b48 in ?? ()
#9  0x00007fbd0239c928 in ?? ()
#10 0x00007fbd02273ed8 in ?? ()
#11 0x00007fbce5bd5ca0 in ?? ()
#12 0x0000000040f9a828 in ?? ()
#13 0x00007fbce5bd6800 in ?? ()
#14 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fbd046667c0 (LWP 4347)):
#0  0x00007fbd0382d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fbcf682301d in ?? () from /usr/lib/nvidia-340/libGL.so.1
#2  0x00007fbcf503d518 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#3  0x00007fbcf4f7f6fe in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#4  0x00007fbcf6819da2 in ?? () from /usr/lib/nvidia-340/libGL.so.1
#5  0x00007fbcf67f33e8 in glXSwapBuffers () from /usr/lib/nvidia-340/libGL.so.1
#6  0x0000000041b7330b in ?? ()
#7  0x00000000013d7760 in ?? ()
#8  0x0000000000000001 in ?? ()
#9  0x0000000000000400 in ?? ()
#10 0x00007ffce6552380 in ?? ()
#11 0x00007ffce6552290 in ?? ()
#12 0x0000000000000500 in ?? ()
#13 0x00000000013e07d0 in ?? ()
#14 0x00007fbd023521e8 in ?? ()
#15 0x00007fbd023521e8 in ?? ()
#16 0x0000000041b73298 in ?? ()
#17 0x00007fbce56349c8 in ?? ()
#18 0x0000000041b7322f in ?? ()
#19 0x00007fbce56890c0 in ?? ()
#20 0x0000000041b731cb in ?? ()
#21 0x00007fbd023521e8 in ?? ()
#22 0x0000000040f98ed0 in ?? ()
#23 0x00007fbd023521e8 in ?? ()
#24 0x00007fbd023521e8 in ?? ()
#25 0x0000000000000000 in ?? ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted (core dumped)

To gain access to this slightly more complete stack trace yourself, enter the following shell command once as root:
echo 0 > /proc/sys/kernel/yama/ptrace_scope

Also I installed the monodevelop-debugger-gdb package (with dependencies).
Any subsequent mono crashes should produce similar output.

Seems to me that the crash might have occurred in thread 2 - see https://devtalk.nvidia.com/default/topic/612078/nvidia-driver-320-86-texture-buffer-bug-leads-to-crash/ - I don't know if that's been fixed.

I also get the sticky Ctrl key problem which is probably related to my strange things that happened with the keys. When I run it without using any Ctrl functions I don't get any issues. I have been getting a very occasional issue with the F10 screen where only blue boxes are visible with no text.

NWM Sounds:
I'm hopeful I've got it licked this time (Famous last words....)

I've only just noticed that the sounds update function is using the time elapsed for each frame to calculate the gain of the sounds it plays (Ouch- whilst OK for a single threaded app, as soon as we introduce multiple render/ update loops, all hell breaks loose......)
The frame time elapsed is zero during initialisation, and so it's been starting playing sounds with a zero-gain...
My previous attempts at fixing this have been performing stops/ restarts on the playing sounds, as I couldn't understand why OpenAL reported it was playing away quite happily

Sticky modifier keys:
Fixed, entirely my fault

jsiren:
That stack trace is more interesting
It's throwing a wobbly when I call GL.GenTextures() on something, and that's taking down the Nvidia driver.
I think this probably means that it's accessing something that doesn't (yet I suspect) exist, as we're nowhere near the texels limit mentioned in your link.

Prime culprit I think is probably the autogen timetable, as that's generated on the fly.

I'll try and get round to knocking up a couple of test trains to test this theory (Two trains with the same panel image, one using panel2.cfg, and the other mapping it to a panel.animated object)

I've also seen a very occasional crash on Windows, which I added a bunch of try-catch blocks to contain. This one isn't quite fixed, as the sim no longer crashes, but F10 and timetables are corrupt, so it all smells very related.

http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440s.7z

Cheers

Chris Lees

http://www.bvecornwall.co.uk

With the "s" version I don't get the sticky Ctrl key problem anymore. With the previous version and the "s" version the sound worked correctly from the start.

More info about the crash, now using version s.
If I load the B'ham X-City South route first with the 323, which comes up fine, then go back to the main menu and load the same route with another engine, this attempt does crash OpenBVE, but does not produce a thread dump, only this:
(gnome-terminal:7975): GLib-GIO-CRITICAL **: g_settings_get: the format string may not contain '&' (key 'monospace-font-name' from schema 'org.gnome.desktop.interface'). This call will probably stop working with a future version of glib.

(gnome-terminal:7975): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2769:41: Expected a valid selector

If I load any other engine first (haven't found any other that works, except for the 323), I get the thread dump as before.

The situation with the joystick: it gets displayed on the control configuration screen, but cannot be used. If I copy over a configuration made with the p version, it's usable. However, the button repeat, REVERSER_FULLAXIS, and SINGLE_FULLAXIS controls don't work correctly. The REVERSER_FULLAXIS control goes from initial neutral to forward and stays there. The SINGLE_FULLAXIS goes from initial EMG to full power and stays there. Any subsequent control must be done with the keyboard controls, if they have been configured. Once the reverser or power lever have been moved with the keyboard controls, the joystick controls have the same effect as described previously (straight to F/full and nothing else). The joystick works perfectly according to jstest, and is accessible on /dev/input/js0.

I found that in 1.4.3 the buttons do repeat as well, only at a much slower rate, so a brief press counts as a single instance.

I'd say anything with a 3D cab is *likely* to work, although I won't guarantee that. I'll go looking for other stock with 3D cabs tomorrow, but they're thin on the ground. (IIRC I've got one tram somewhere plus a LU train of some description & that's it)

On the plus side, I've found the Insert key issue under Linux in OpenTK
Pull request submitted here:
https://github.com/opentk/opentk/pull/313

I'll provide a fixed version of OpenTK in my next build.

Edit:
Copy of build S uploaded with fixed OpenTK.dll
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440s.7z

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Just a remark: there are two lines in options.cfg:
keyRepeatDelay = 500
keyRepeatInterval = 100
  - have these got anything to do with the joystick button repeat thing?