New OpenBVE Build- Testers Please

Also, if it helps, I can provide core files and Mono traces.

I have been using the "second" s-build now. The program still crashes on linux unless the C-Stock v3 is being used. The error message shown in the terminal is as follows:

Code:

Stacktrace:


Native stacktrace:

 mono() [0x4b73d8]
 mono() [0x50f13b]
 mono() [0x423d22]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f2ce1a91340]
 /usr/lib/nvidia-304/libGL.so.1(+0x2f91a9) [0x7f2cc90f81a9]

Debug info from gdb:

AL lib: ReleaseALC: 1 device not closed

=================================================================
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.
=================================================================


I would like to offer you a core dump too, but my OS seems to hide it somewhere ...

Moreover the keys now seem to be "stuck" after a while. It seems as if someone pressed them all the time -- the A.I. has to "fight" against these "pressed" keys, too.

_sando_, run this as root:
echo 0 > /proc/sys/kernel/yama/ptrace_scope
After this (until the next reboot, or until you run echo 1 etc.) the stack dump is much more informative. This is not normally enabled, since it may be a slight security risk in some situations. Therefore you can run - again, as root -
echo 1 > /proc/sys/kernel/yama/ptrace_scope
once you have the stack dump you want. Always run OpenBVE as a regular user, not as root.

Also, if you  want core files for debugging, run this as yourself (the regular user) in the same shell where you start OpenBVE:
ulimit -c unlimited
Now the core file will be created. This will persist until you close the shell.

Hello jsiren,

thank you for your advice. I've got the dump file now.

It seems to be VERY large -- 176 MiB ... (How can I submit that?)

By the way, I had to execute another echo "core-%e-%p-%s-%c" > /proc/sys/kernel/core_pattern because the kernel wanted all core files to be squirreled away by apport.

jsiren wrote: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?

Not really
You can do one of two things to handle key repeats- Either you can let the OS take care of it (The repeat rate will be under Keyboard Settings somewhere), or you can hook into the key up/ down events and send repeats yourself.
OpenBVE handles it's own repeat functionality, mainly because you want a much slower repeat rate for power notches than you would for typing- Try holding down a key in your favourite word processing app, and seeing how fast it repeats; You don't want to change power notches that fast!

Having checked the C-Stock, it's got a 3D cab, so at least both of you are seeing what's hopefully the same bug!

Can't reproduce any sticking keys at the minute, will have to do a couple of long driving runs under Linux and see if anything happens.

Back to more interesting matters-
Can one (or both) of you please try the two trains in the attachment, and see if either crashes?
Test1 is a simple panel2.cfg, with day and night images for the main panel, and nothing else.
Test2 is the daytime panel image, but loaded via a panel.animated

If these both work, I can add back in the needles/ gauges until we discover what's actually causing it to crash. If I know that, I can do some proper digging into how it's loading the texture into memory etc.

On the flip side, whilst cooking these, I've fixed a couple of issues with multi-threaded error handling, which will be in the next build. Nothing really interesting, but the sim will now show a nice error message and restart to the main menu in a couple of cases, rather than just vanishing into thin air

Cheers

Chris Lees

http://www.bvecornwall.co.uk

test1: crashed on SIGSEGV when loading train at 10.3%. Stack dump at end of post. Core file available on request.
test2: crashed on System.NullReferenceException when loading train at 10.3%. Error message at end of post. No core dumped.

test1 stack dump:
$ mono OpenBve.exe
Stacktrace:


Native stacktrace:

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

Debug info from gdb:

  File "/usr/lib/debug/usr/bin/mono-sgen-gdb.py", line 112
    print sys.exc_info ()[0]
            ^
SyntaxError: invalid syntax
[New LWP 10450]
[New LWP 10449]
[New LWP 10448]
[New LWP 10445]
[New LWP 10442]
[New LWP 10441]
[New LWP 10439]
[New LWP 10438]
[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'
0x00007fd89ee7d12d 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 0x7fd89c30f700 (LWP 10438) "mono" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  8    Thread 0x7fd892abf700 (LWP 10439) "SDLTimer" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  7    Thread 0x7fd8886cf700 (LWP 10441) "dconf worker" 0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  6    Thread 0x7fd887ece700 (LWP 10442) "gdbus" 0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  5    Thread 0x7fd8869af700 (LWP 10445) "gmain" 0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  4    Thread 0x7fd875fff700 (LWP 10448) "threaded-ml" 0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
  3    Thread 0x7fd8717f7700 (LWP 10449) "mono" 0x00007fd89f167b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7fd88523f700 (LWP 10450) "mono" 0x00007fd89f167ee9 in __libc_waitpid (pid=pid@entry=10451, stat_loc=stat_loc@entry=0x7fd89fc2719c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
* 1    Thread 0x7fd89fcb57c0 (LWP 10437) "mono" 0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81

Thread 9 (Thread 0x7fd89c30f700 (LWP 10438)):
#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=0x1af0700) at threads.c:643
#4  start_wrapper (data=0x1af0700) at threads.c:688
#5  0x000000000062410d in thread_start_routine (args=args@entry=0x1a733e8) at wthreads.c:294
#6  0x0000000000633ef5 in inner_start_thread (arg=0x1af05a0) at mono-threads-posix.c:49
#7  0x00007fd89f160182 in start_thread (arg=0x7fd89c30f700) at pthread_create.c:312
#8  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7fd892abf700 (LWP 10439)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007fd8973b952e in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#2  0x00007fd8973b9675 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#3  0x00007fd89736eba1 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007fd89736e73d in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007fd8973b9279 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6  0x00007fd89f160182 in start_thread (arg=0x7fd892abf700) at pthread_create.c:312
#7  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7fd8886cf700 (LWP 10441)):
#0  0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd88e158fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fd88e1590ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fd8886d71ad in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007fd88e17df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fd89f160182 in start_thread (arg=0x7fd8886cf700) at pthread_create.c:312
#6  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7fd887ece700 (LWP 10442)):
#0  0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd88e158fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fd88e15930a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fd88a1e7336 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007fd88e17df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fd89f160182 in start_thread (arg=0x7fd887ece700) at pthread_create.c:312
#6  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7fd8869af700 (LWP 10445)):
#0  0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd88e158fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fd88e1590ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fd88e159129 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fd88e17df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fd89f160182 in start_thread (arg=0x7fd8869af700) at pthread_create.c:312
#6  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fd875fff700 (LWP 10448)):
#0  0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd896be0031 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x00007fd896bd183c in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x00007fd896bd1ece in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x00007fd896bd1f80 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x00007fd896bdffe3 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x00007fd894f95f08 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so
#7  0x00007fd89f160182 in start_thread (arg=0x7fd875fff700) at pthread_create.c:312
#8  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fd8717f7700 (LWP 10449)):
#0  0x00007fd89f167b9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd88526754a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#2  0x00007fd8852745eb in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#3  0x00007fd885266e6a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#4  0x00007fd89f160182 in start_thread (arg=0x7fd8717f7700) at pthread_create.c:312
#5  0x00007fd89ee8a47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fd88523f700 (LWP 10450)):
#0  0x00007fd89f167ee9 in __libc_waitpid (pid=pid@entry=10451, stat_loc=stat_loc@entry=0x7fd89fc2719c, 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=0x7fd89fc27ac0) at mini-exceptions.c:2299
#2  0x000000000050f13b in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7fd89fc27ac0, fault_addr=, stack_ovf=stack_ovf@entry=0) at exceptions-amd64.c:908
#3  0x0000000000423d22 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fd89fc27bf0, context=0x7fd89fc27ac0) at mini.c:6769
#4  
#5  0x00007fd892047c09 in glGenTextures () from /usr/lib/nvidia-340/libGL.so.1
#6  0x000000004096baa9 in ?? ()
#7  0x00007fd89c400200 in ?? ()
#8  0x00007fd89c4a9f38 in ?? ()
#9  0x00007fd89da32dc0 in ?? ()
#10 0x00007fd89da866a0 in ?? ()
#11 0x00007fd88523dca0 in ?? ()
#12 0x00000000415c5748 in ?? ()
#13 0x00007fd88523e800 in ?? ()
#14 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7fd89fcb57c0 (LWP 10437)):
#0  0x00007fd89ee7d12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fd89202301d in ?? () from /usr/lib/nvidia-340/libGL.so.1
#2  0x00007fd89083d518 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#3  0x00007fd89077f6fe in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#4  0x00007fd892019da2 in ?? () from /usr/lib/nvidia-340/libGL.so.1
#5  0x00007fd891ff33e8 in glXSwapBuffers () from /usr/lib/nvidia-340/libGL.so.1
#6  0x000000004096f15b in ?? ()
#7  0x0000000001ae6760 in ?? ()
#8  0x0000000000000001 in ?? ()
#9  0x0000000000000400 in ?? ()
#10 0x00007fffd38147c0 in ?? ()
#11 0x00007fffd38146d0 in ?? ()
#12 0x0000000000000500 in ?? ()
#13 0x0000000001aeecd0 in ?? ()
#14 0x00007fd89d80d8a0 in ?? ()
#15 0x00007fd89d80d8a0 in ?? ()
#16 0x000000004096f0e8 in ?? ()
#17 0x00007fd884c44a00 in ?? ()
#18 0x000000004096f07f in ?? ()
#19 0x00007fd884c8c568 in ?? ()
#20 0x000000004096f01b in ?? ()
#21 0x00007fd89d80d8a0 in ?? ()
#22 0x00000000415c3ed0 in ?? ()
#23 0x00007fd89d80d8a0 in ?? ()
#24 0x00007fd89d80d8a0 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)

test2 error message:
$ mono OpenBve.exe
Could not set X locale modifiers

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at OpenBve.TrainManager.ParsePanelConfig (System.String TrainPath, System.Text.Encoding Encoding, OpenBve.Train Train) [0x00000] in :0 
  at OpenBve.Loading.LoadEverythingThreaded () [0x00000] in :0 
  at OpenBve.Loading.LoadThreaded () [0x00000] in :0 
  at System.Threading.Thread.StartInternal () [0x00000] in :0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at OpenBve.TrainManager.ParsePanelConfig (System.String TrainPath, System.Text.Encoding Encoding, OpenBve.Train Train) [0x00000] in :0 
  at OpenBve.Loading.LoadEverythingThreaded () [0x00000] in :0 
  at OpenBve.Loading.LoadThreaded () [0x00000] in :0 
  at System.Threading.Thread.StartInternal () [0x00000] in :0 
AL lib: ReleaseALC: 1 device not closed

On a completely unrelated note: the notching speed depends greatly on the stock. The default values are a reasonable average for keyboard driving. However, the repeat rate of the joystick buttons could have the same default value, as they repeat quite fast now. With jstest or qjoypad they do not repeat at all.

Well, that tells me something reasonably useful, but I can't see why at the minute-
The only place it can be crashing (Assuming that is that you're loading a working routefile) is when it loads the panel daytime image, which it does into the first OpenGL texture slot.

I have the nasty suspicion that something is threading somewhere, and so it's trying to call OpenGL without a valid context.
That doesn't explain why it works OK on anything but Nvidia though.....
Need to do some more thinking....

Test2 crashing is probably my fault- Zipped up the one I was using to crash test the corrupt panel code....

Try the attached Test2, and see if that dumps on you.

I'm going to have to try and get my hands on a Nvidia box though; I need to try stepping through this with a debugger line by line

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Seeing as I have an nVidia box right here, given the source code, I could also step through it and see what happens - if it helps.

Short answer is not really
As the minimal train crashes, I'm reasonably certain it's dumping out when it enters the Textures.LoadTexture function called on line 174:
https://github.com/leezer3/OpenBVE/blob/bb14ee902e5bb790aadd71d1d211635f6ba77e75/openBVE/OpenBve/OldParsers/Panel2CfgParser.cs
(That's a link to the source for the version in the post above)

The only real reason for it to be doing that is the lack of a valid context on the caller thread. It's not doing anything interesting with OpenGL, just loading a texture into memory.
Now, in theory, and on Windows and my Linux VMs, the context should be shared across, but it plainly isn't happening....

This build is a blind shot at fixing this, by specifically passing the texture load call back into the loading screen loop function.
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440t.7z

I'm also investigating why texture loading on the fly for panel images doesn't work, which seems a little odd-
Internally in memory, the panel is just another animated object, built whilst loading.
In theory, the textures should be loaded on the fly, but this isn't working for panel objects....



Cheers

Chris Lees

http://www.bvecornwall.co.uk

And the new test2 train didn't crash.

Okay, now the 2D cabs seem to work. The locomotives I tested - with both 2D and 3D cabs seem to run just fine. The framerate is great (probably as good as it gets with my miserable nVidia 210) and everything runs smoothly. Keyboard controls work as expected, and the train is fully drivable with the keyboard. Sounds work fine as far as I can hear. I saw some jumpiness in one run, but that should be related to my machine running out of memory and having to swap (I have a lot of stuff open right now). The remarkable bit about this is that the program recovered gracefully from slowness of the computer, whereas previously there have been strange problems like trains jumping all over the track.

I tested trains with UkTrainSys and BVEC_ATS plugins, both seem to work.

A few issues remain:
* The presence of a joystick seems to be detected; when it's unplugged, it doesn't show up in the Customize controls screen. When plugged in, it does show up, but none of the axis motions or button presses are shown. Therefore I cannot assign any controls to the joystick.
* Even if the Customize controls screen doesn't show axis motions, the actual simulation screen does detect some motion; however, each axis seems to be ON only (not even on/off). That is to say, moving the axis assigned to the SINGLE_FULLAXIS control from 0 up (maximum as per jstest is +32k) moves the power/brake handle straight to maximum power. Moving the axis bax to 0 or negative values (down to -32k) doesn't reduce power or initiate braking; it remains at full. (The axis motions as reported by jstest are zero centered, and the positive side is toward me, clockwise, and to the right, respectively.)
* Also, the problem remains with the joystick buttons repeating so fast that one brief tap is the equivalent of a coin toss. (in jstest there's no repeat at all) It takes several tries to switch the lights or DRA off or on.
* AWS seems to acknowledge itself - the sunflower appears by itself without any sound. However, the "ding" of a clear signal does sound. Everything else in the security system works, though - vigilance device, DRA, pantograph, lights, doors...

jsiren wrote:Okay, now the 2D cabs seem to work. The locomotives I tested - with both 2D and 3D cabs seem to run just fine. The framerate is great (probably as good as it gets with my miserable nVidia 210) and everything runs smoothly. Keyboard controls work as expected, and the train is fully drivable with the keyboard. Sounds work fine as far as I can hear. I saw some jumpiness in one run, but that should be related to my machine running out of memory and having to swap (I have a lot of stuff open right now). The remarkable bit about this is that the program recovered gracefully from slowness of the computer, whereas previously there have been strange problems like trains jumping all over the track.

Same thing here -- everything works fine now. Great job, Chris.

However, there is still one issue: Some trains still lead to crashes while loading on my linux machine. I have no idea (yet) what the reason might be, but these trains are older (dating back from the early-mid 2000s) and seem to have a kind of "sloppy" configuration in common. One of the most "reliable" trains in this context is the BR480-2 train that can be obtained from this site.

The BR480-2 seems to be made for BVE 2.6.2, so no surprise there. Have you tried it on OpenBVE 1.4.3?

Ah, I see. I am just wondering a little about that because these old trains have always worked (apart from that little png-crashes-your-libgdiplus bug some time ago) both on linux and windows -- and they still work on windows.

Because _sando_ said the old trains have been working, I tried the BR480 in 1.4.3 and 1.4.4.0t on Linux. In 1.4.3 it does work. In 1.4.4.0t it crashes reliably at the point where 7.7% of train has been loaded. The resulting stack trace is in the bottom of this post.

Stacktrace:


Native stacktrace:

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

Debug info from gdb:

  File "/usr/lib/debug/usr/bin/mono-sgen-gdb.py", line 112
    print sys.exc_info ()[0]
            ^
SyntaxError: invalid syntax
[New LWP 24833]
[New LWP 24832]
[New LWP 24831]
[New LWP 24824]
[New LWP 24821]
[New LWP 24820]
[New LWP 24819]
[New LWP 24818]
[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'
0x00007f8d30e8512d 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 0x7f8d2e30f700 (LWP 24818) "mono" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  8    Thread 0x7f8d24a87700 (LWP 24819) "SDLTimer" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  7    Thread 0x7f8d1a687700 (LWP 24820) "dconf worker" 0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
  6    Thread 0x7f8d19e86700 (LWP 24821) "gdbus" 0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
  5    Thread 0x7f8d18967700 (LWP 24824) "gmain" 0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
  4    Thread 0x7f8d08fef700 (LWP 24831) "threaded-ml" 0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
  3    Thread 0x7f8cfffff700 (LWP 24832) "mono" 0x00007f8d3116fb9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7f8d0a8d7700 (LWP 24833) "mono" 0x00007f8d3116fee9 in __libc_waitpid (pid=pid@entry=24837, stat_loc=stat_loc@entry=0x7f8d31c2f19c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
* 1    Thread 0x7f8d31cb87c0 (LWP 24817) "mono" 0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81

Thread 9 (Thread 0x7f8d2e30f700 (LWP 24818)):
#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=0x1c0f700) at threads.c:643
#4  start_wrapper (data=0x1c0f700) at threads.c:688
#5  0x000000000062410d in thread_start_routine (args=args@entry=0x1b923e8) at wthreads.c:294
#6  0x0000000000633ef5 in inner_start_thread (arg=0x1c0f5a0) at mono-threads-posix.c:49
#7  0x00007f8d31168182 in start_thread (arg=0x7f8d2e30f700) at pthread_create.c:312
#8  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7f8d24a87700 (LWP 24819)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007f8d2d3b952e in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#2  0x00007f8d2d3b9675 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#3  0x00007f8d2d36eba1 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x00007f8d2d36e73d in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#5  0x00007f8d2d3b9279 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6  0x00007f8d31168182 in start_thread (arg=0x7f8d24a87700) at pthread_create.c:312
#7  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7f8d1a687700 (LWP 24820)):
#0  0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d20118fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8d201190ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8d1a68f1ad in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007f8d2013df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f8d31168182 in start_thread (arg=0x7f8d1a687700) at pthread_create.c:312
#6  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 6 (Thread 0x7f8d19e86700 (LWP 24821)):
#0  0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d20118fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8d2011930a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8d1c19f336 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007f8d2013df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f8d31168182 in start_thread (arg=0x7f8d19e86700) at pthread_create.c:312
#6  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7f8d18967700 (LWP 24824)):
#0  0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d20118fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f8d201190ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f8d20119129 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f8d2013df05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f8d31168182 in start_thread (arg=0x7f8d18967700) at pthread_create.c:312
#6  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7f8d08fef700 (LWP 24831)):
#0  0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d2cbe0031 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x00007f8d2cbd183c in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x00007f8d2cbd1ece in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x00007f8d2cbd1f80 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#5  0x00007f8d2cbdffe3 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6  0x00007f8d26f5df08 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-4.0.so
#7  0x00007f8d31168182 in start_thread (arg=0x7f8d08fef700) at pthread_create.c:312
#8  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f8cfffff700 (LWP 24832)):
#0  0x00007f8d3116fb9d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d0aebf54a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#2  0x00007f8d0aecc5eb in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#3  0x00007f8d0aebee6a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#4  0x00007f8d31168182 in start_thread (arg=0x7f8cfffff700) at pthread_create.c:312
#5  0x00007f8d30e9247d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f8d0a8d7700 (LWP 24833)):
#0  0x00007f8d3116fee9 in __libc_waitpid (pid=pid@entry=24837, stat_loc=stat_loc@entry=0x7f8d31c2f19c, 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=0x7f8d31c2fac0) at mini-exceptions.c:2299
#2  0x000000000050f13b in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7f8d31c2fac0, fault_addr=, stack_ovf=stack_ovf@entry=0) at exceptions-amd64.c:908
#3  0x0000000000423d22 in mono_sigsegv_signal_handler (_dummy=11, info=0x7f8d31c2fbf0, context=0x7f8d31c2fac0) at mini.c:6769
#4  
#5  0x00007f8d23f97c09 in glGenTextures () from /usr/lib/nvidia-340/libGL.so.1
#6  0x000000004016d1b9 in ?? ()
#7  0x00007f8d2faa6628 in ?? ()
#8  0x00007f8d2e400200 in ?? ()
#9  0x00007f8d2f8f8918 in ?? ()
#10 0x00007f8d2faa9938 in ?? ()
#11 0x00007f8d0a8d5580 in ?? ()
#12 0x0000000040ff78d8 in ?? ()
#13 0x00007f8d0a8d67b0 in ?? ()
#14 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f8d31cb87c0 (LWP 24817)):
#0  0x00007f8d30e8512d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f8d23f7301d in ?? () from /usr/lib/nvidia-340/libGL.so.1
#2  0x00007f8d2278d518 in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#3  0x00007f8d226cf6fe in ?? () from /usr/lib/nvidia-340/libnvidia-glcore.so.340.93
#4  0x00007f8d23f69da2 in ?? () from /usr/lib/nvidia-340/libGL.so.1
#5  0x00007f8d23f433e8 in glXSwapBuffers () from /usr/lib/nvidia-340/libGL.so.1
#6  0x000000004017085b in ?? ()
#7  0x0000000001c05760 in ?? ()
#8  0x0000000000000001 in ?? ()
#9  0x0000000000000400 in ?? ()
#10 0x00007fff1bc62d60 in ?? ()
#11 0x00007fff1bc62c70 in ?? ()
#12 0x0000000000000500 in ?? ()
#13 0x0000000001c0e7d0 in ?? ()
#14 0x00007f8d2f901e58 in ?? ()
#15 0x00007f8d2f901e58 in ?? ()
#16 0x00000000401707e8 in ?? ()
#17 0x00007f8d0b9d8a18 in ?? ()
#18 0x000000004017077f in ?? ()
#19 0x00007f8d0913fa60 in ?? ()
#20 0x000000004017071b in ?? ()
#21 0x00007f8d2f901e58 in ?? ()
#22 0x0000000040ff6060 in ?? ()
#23 0x00007f8d2f901e58 in ?? ()
#24 0x00007f8d2f901e58 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)

Entirely my fault, it's the same bug, I just hadn't fixed it for panel.cfg loads, which are predictably enough in a different class


Updated copy of built T, applying the same fix:
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440t.7z

Physics fixed when FPS gets slow:
The root cause of this will be the same bouncing on loading bug I couldn't reproduce at the start of the thread.
OpenBVE uses the last frame elapsed time in a *lot* of calculations. When this gets too high (I think about a second, although I can't get it to reproduce), some calculation results start to roll over.
I've made a hack, which turns off toppling if a frame takes more than a second to render.

Joysticks:
On my list of things to properly dig into. The code for these at the moment isn't the best

Cheers

Chris Lees

http://www.bvecornwall.co.uk

The BR480 loads properly in 1.4.4.0.t.bis.

I had the "last frame elapsed time roll over" bug when my hard drive was failing and the computer was freezing for seconds at a time. The effect was that the entire train got flipped back to front, so in effect I ended up in the "rear cab". Funnily enough, I was able to continue driving in either direction. Unfortunately I haven't been able to reproduce this in a controlled manner...

There's a strange bug in the t version in that the cab panel isn't renderered, just the gauges like brakes and speedo needle along with wipers. This seams to happen with all the trains that I've tried so far.

LabRatAndy wrote:There's a strange bug in the t version in that the cab panel isn't renderered, just the gauges like brakes and speedo needle along with wipers. This seams to happen with all the trains that I've tried so far.  

I've got the same problem -- I am not quite sure but it seems to happen with trains that have a 2D cab and use some sort of plugin. I have tested so far the Class 323 EMU, the Class 950 DMU, the Class 60 loco, the LT1995 stock, the Czech class 754 and the American R16 and R40 slant type trains. All of these show no panel but some/all needles, wipers and handles, both on Windows and Linux.

But the BR480-2 works properly now.

My results:
* Class 323 (3D cab, UkTrainSys.dll) works.
* Class 60 (2D cab, UkTrainSys.dll) no cab, only needles.
* CD 164 (2D cab, BVEC_ATS.dll): no cab, only needles.
* BR480-2 (2D panel.cfg cab, no plugin) works.
* test1 (OS_ATS plugin demo train, 2D cab) no cab whatsoever as far as I can see
* test2 (OS_ATS plugin demo train, 3D cab) cab loads, cannot open cab because of incompatible plugin

I tried all of the above in the older t version, and they all work (meaning that the cab is displayed correctly), except of course the BR480-2.

With your updated t version I also get the problem with the 2D cab not rendering properly on windows. This was tested on the 2D cab class 323, class 150 and the class 104 and they all have this problem. Only the wipers, needles and some small sections of the cab is present with the rest missing. This problem does not happen with the 3D cab class 323.

Oh heck, typo, I thought that wasn't in the build I pushed.....
(Specifically, I left in two commented out two lines by mistake whilst trying to figure out why the panel.cfg trains were crashing: https://github.com/leezer3/OpenBVE/commit/7729ec46709773393c198a7030da99371d3aa594 )

Build U:
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1440u.7z

Changes-
Fixes the missing cab elements.
Changes two For loops to use Parallel.For in the train update function- This gives a small FPS boost on CPU limited systems. (With VSYNC off, my minimal test route goes from ~180fps to ~190fps, but this gain is likely to fall a lot with more complex scenery)
Attempted fix for sticky keys problem, by specifically blocking the OpenBVE key repeat function from running whilst a keydown/ keyup event is in progress.

I'm going to see whether I can change more of the loops for Parallel.For, which for cases in which the execution order doesn't actually matter, would seem to improve the speed by a magnitude of ~4

Cheers

Chris Lees

http://www.bvecornwall.co.uk

That has fixed the missing train cab. I can't say that I noticed improved frame rates but did seam to be smoother. However it looks like the missing sound on NWM routes bug is back again.