search

virtualglobebook / OpenGlobe

A 3D engine for virtual globes (think Google Earth or NASA World Wind) designed to illustrate the engine design and rendering techniques described in our book. OpenGlobe is written in C# and uses OpenGL 3.3 core profile (via OpenTK). See the web site linked below for more information
http://www.virtualglobebook.com
Other
345 stars 113 forks source link

Chapter 13 segfaults in Mono under Ubuntu, but runs OK (but slowly) in debug mode. #1

Open 626Pilot opened 11 years ago

626Pilot commented 11 years ago

I can get every chapter to run, except for the last. It starts downloading terrain from NASA. The window will show up. But then, almost immediately, it crashes. I noticed some SIGPWR and SIGXCPU signals being raised right before it crashes. SIGPWR I have no idea about. SIGXCPU means it exceeded the allowed CPU time, but the CPU usage limit is infinite. (I read somewhere that Mono uses SIGXCPU internally, so it doesn't actually mean that.)

For some odd reason, it doesn't crash if I run it in debug mode. (It just runs really, REALLY slow.) Since it won't crash that way, I can't step through the code and find out where the issue is myself. The code was compiled with MonoDevelop 3.0.3.2, which is the standard version you get with Ubuntu. Mono is also the standard version.

I also tried running mono with --trace turned on, but it never produced an actual window or crashed after half an hour, so I gave up.

Here's some info I collected. Let me know if anything else is needed.

Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-5ubuntu1)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            Included Boehm (with typed GC and Parallel Mark)

strace output, near the end:

futex(0x8f0cc0, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted) --- SIGPWR (Power failure) @ 0 (0) --- futex(0x926fc0, FUTEX_WAKE_PRIVATE, 1) = 1 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1]) = ? ERESTARTNOHAND (To be restarted) --- SIGXCPU (CPU time limit exceeded) @ 0 (0) --- rt_sigreturn(0x7f8a9fda5740) = -1 EINTR (Interrupted system call) futex(0x926fc0, FUTEX_WAKE_PRIVATE, 1) = 1 rt_sigreturn(0x926fc0) = 202 futex(0x8f0cc0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 futex(0x8f0cc0, FUTEX_WAKE_PRIVATE, 1) = 0 getpid() = 7710 getpid() = 7710 getpid() = 7710 (getpid repeated about 100 more times...) Stacktrace:

Native stacktrace:

getpid() = 7710 getpid() = 7710 getpid() = 7710 getpid() = 7710 getpid() = 7710 getpid() = 7710 getpid() = 7710 getpid() = 7710 +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)

kring commented 11 years ago

Thanks for the bug report. What GPU do you have? I believe, by default, Ubuntu uses an open source driver on NVidia GPUs (and possibly others), and provides an option to install the official NVidia one. Does your GPU have this situation? If so, have you tried both drivers?

626Pilot commented 11 years ago

This is on a GeForce GTX 660 running the 310.14 drivers (OS standard.) I don't use the open source drivers since they are no good for 3D. I also tried with newer drivers and had the same result.

I nuked my copy and cloned fresh from the repo so I could try again. Crashes seem to happen anywhere from immediately to several minutes in. Sometimes the window will appear for a moment and immediately crash, and other times it will run for a few minutes. Running it several times in a row and just leaving it alone completely yields a different result each time. Sometimes the console will show it downloading two terrain files from NASA and then crashing; other times it will download six or ten; at the moment it's downloaded hundreds. I don't know of any obvious thing that would change from one session to the next except that it takes varying amounts of time to connect and download the terrain data. Off the top of my head, I guess it's possible that it could be trying to render based on data that isn't there yet?

Framerate also doesn't seem too good even in Release mode. It's fine in other OpenGL apps.

626Pilot commented 11 years ago

Did a little more testing. I let it run untouched until it had downloaded everything it wanted to for the default view. It doesn't seem to crash if the camera is not moved, even for long periods. Switched to flycam and started zooming around the planet at 20KM/sec. It was fine for about 30 seconds, but then it crashed. (It will also crash in look-at.)

kring commented 11 years ago

I just tried it out on my Ubuntu 11.04 system with an NVidia GTS 250 and NVidia driver version 280.13. No issues that I could see. Performance could be better (and it is in Windows) but it's not terrible. I'll upgrade to 12.04 (Update Manager isn't giving me the option to go to 12.10?) and try again. If you have any other ideas for things I might try, let me know.

By the way, if you're looking for a solid example of a terrain engine, I recommend you take a look at Cesium (http://cesium.agi.com/). It's much more polished and performant engine than the one in OpenGlobe, and I say that as the author of both. Cesium is JavaScript and WebGL if that sways you either way.

626Pilot commented 11 years ago

You might have to upgrade stepwise. 12.04 is the long term support release. I installed 12.10 because a lot of the libs and apps are newer / get updated more often, and I figured it was the frontrunner Linux distro that most gamers would be likely to use. (Valve Software has the same idea.) We were hoping to use something C# / regular OpenGL based, and we have copies of the 3D Globes book, so we figured we'd start from here. It might just be down to the newer version of Mono being touchy about something. Can you tell me the Mono version you have, and the output of ldd /path/to/mono? Maybe that will help narrow it down. Also, are you using 32- or 64-bit? That seems to make a difference.

Here's the shared libs on 64-bit 12.10:

ldd /usr/bin/mono                                                                                                                                                                                                                                                   
        linux-vdso.so.1 =>  (0x00007fffdf7ff000)                                                                                                                                                                                                                               
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f63e30f4000)                                                                                                                                                                                                      
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f63e2eec000)                                                                                                                                                                                                    
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f63e2ce7000)                                                                                                                                                                                                    
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f63e2aca000)                                                                                                                                                                                          
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f63e270b000)                                                                                                                                                                                                      
        /lib64/ld-linux-x86-64.so.2 (0x00007f63e341d000)

We also compiled Chapter 13 using Xamarin or whatever it's called (monodevelop derivative) on Windows, and it didn't crash, although it would have been running on .Net rather than Mono. (So much for "write once, run everywhere.") I will have our client dev guy look at Cesium. Is there anything off the top of your head that would make it render so much faster? It runs great on Chromium!

kring commented 11 years ago

It was the 64-bit version, and I believe Mono 2.10.5. The upgrade to 12.04 totally busted me though - my keyboard and mouse don't work anymore. I'll do a clean install of 12.10 and try that, but give me a few days.

I guess there are a number of reasons Cesium might be faster. It's a different terrain LOD algorithm, for one thing. Cesium closely follows Chapter 14 in our book (Chunked LOD). Cesium is also much more mature and optimized, even though there is plenty more to be done. The JavaScript engine in Chromium is also perhaps generating more optimal code than Mono's .NET runtime.

kring commented 11 years ago

I did a clean install of 64-bit 12.10. It took me a few to figure out how to install the proprietary NVidia driver (it didn't pop right up with it as it had in previous versions of Ubuntu), but once I did, the clipmap example worked well in both the debug and release configurations. I'm using driver version 304.51 according to nvidia-settings, which I got by installing nvidia-current-updates. Also Mono and gmcs version 2.10.8.1, and MonoDevelop 3.0.3.2. Here's the output from ldd /usr/bin/mono:

    linux-vdso.so.1 =>  (0x00007fffa7fff000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fba4d67b000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fba4d473000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fba4d26e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fba4d051000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fba4cc92000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fba4d98d000)

I tried installing the experimental NVidia driver first, and after I rebooted and logged in, I got a blank screen with just the mouse cursor and the desktop background instead of the normal Unity environment. I was able to fix it by issuing these commands, following instructions I found somewhere:

sudo apt-get install inux-source
sudo apt-get install linux-headers-generic
sudo apt-get remove nvidia-current-updates
sudo apt-get install nvidia-current-updates

I mention this in the unlikely event that installing the linux source or headers somehow made a difference for OpenGlobe.

Have you been able to duplicate the problems you see on another machine?

626Pilot commented 11 years ago

I tried reinstalling mono and libmono:

sudo apt-get install --reinstall `dpkg -l |grep 'mono' |awk '{print $2}'`

It seemed to be more willing to run, but eventually it would crash again...

Managed to get another trace out of it:

Stacktrace:

at (wrapper managed-to-native) object.wrapper_native_0x7f334f9c4740     (OpenTK.Graphics.OpenGL.FramebufferTarget,uint) <IL 0x00024, 0xffffffff>
at OpenTK.Graphics.OpenGL.GL.BindFramebuffer (OpenTK.Graphics.OpenGL.FramebufferTarget,int) <IL 0x00007, 0x0002d>
at OpenGlobe.Renderer.GL3x.FramebufferGL3x.UnBind () <IL 0x00000, 0x0000f>
at OpenGlobe.Renderer.GL3x.ContextGL3x.ApplyFramebuffer () <IL 0x0002c, 0x00043>
at OpenGlobe.Renderer.GL3x.ContextGL3x.Clear (OpenGlobe.Renderer.ClearState) <IL 0x00001, 0x0001b>
at OpenGlobe.Examples.ClipmapTerrainOnGlobe.OnRenderFrame () <IL 0x00013, 0x0002f>
at OpenGlobe.Renderer.GraphicsWindow.OnRenderFrame () <IL 0x0000e, 0x0001d>
at OpenGlobe.Renderer.GL3x.GraphicsWindowGL3x.OnRenderFrame<T> (object,T) <IL 0x00007, 0x00024>
at OpenTK.GameWindow.OnRenderFrame (OpenTK.FrameEventArgs) <IL 0x00010, 0x00035>
at OpenTK.GameWindow.OnRenderFrameInternal (OpenTK.FrameEventArgs) <IL 0x00012, 0x00038>
at OpenTK.GameWindow.RaiseRenderFrame   (System.Diagnostics.Stopwatch,double&,OpenTK.FrameEventArgs) <IL 0x000ee, 0x0024b>
at OpenTK.GameWindow.DispatchUpdateAndRenderFrame (object,System.EventArgs) <IL 0x0002b, 0x0005b>
at OpenTK.GameWindow.Run (double,double) <IL 0x000c0, 0x0023f>
at OpenTK.GameWindow.Run (double) <IL 0x0000b, 0x00023>
at OpenGlobe.Renderer.GL3x.GraphicsWindowGL3x.Run (double) <IL 0x00001, 0x00027>
at OpenGlobe.Examples.ClipmapTerrainOnGlobe.Run (double) <IL 0x00007, 0x00026>
at OpenGlobe.Examples.ClipmapTerrainOnGlobe.Main () <IL 0x00006, 0x00047>
at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <IL 0x0004c, 0xffffffff>

Native stacktrace:

/usr/bin/mono() [0x4961e9]
/usr/bin/mono() [0x4e6d1f]
/usr/bin/mono() [0x41dcb7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f335ba21cb0]
/usr/lib/nvidia-current-updates/libnvidia-glcore.so.304.51(+0x111bb53) [0x7f334e1f7b53]
/usr/lib/nvidia-current-updates/libnvidia-glcore.so.304.51(+0x10cffb8) [0x7f334e1abfb8]
/usr/lib/nvidia-current-updates/libnvidia-glcore.so.304.51(+0x1355409) [0x7f334e431409]
/usr/lib/nvidia-current-updates/libGL.so.1(+0x7aac9) [0x7f334f743ac9]

I might just have to try reinstalling. It's a different problem every run.