Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A mysterious crash #9

Open
deepfire opened this issue Mar 7, 2017 · 18 comments
Open

A mysterious crash #9

deepfire opened this issue Mar 7, 2017 · 18 comments

Comments

@deepfire
Copy link
Contributor

deepfire commented Mar 7, 2017

Circumstances:

  • reproducibility: good
  • commit: last hackage release
  • scenario: repeated calls to:
  dGPUMesh      ← GL.uploadMeshToGPU dMesh
  dGLObject     ← GL.addMeshToObjectArray osStorage (fromOANS osObjArray) [unameStr osUniform, "viewProj"] dGPUMesh
  dTexture      ← uploadTexture2DToGPU'''' False False False False $ (fromWi dStridePixels, h, GL_BGRA, pixels) -- a slightly hacked up version of uploadTexture2DToGPU
  GL.updateObjectUniforms dGLObject $ do
    fromUNS osUniform GL.@= return dTexture
  • stack is always the same:
Thread 4 "ghc_worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb511270700 (LWP 11780)]
0x00007fb518faecac in __memmove_sse2_unaligned_erms ()
   from /nix/store/33f49v0xhayfnj6ldk6nzqbw2hlvcrix-glibc-2.24/lib/libc.so.6
(gdb) bt
#0  0x00007fb518faecac in __memmove_sse2_unaligned_erms ()
   from /nix/store/33f49v0xhayfnj6ldk6nzqbw2hlvcrix-glibc-2.24/lib/libc.so.6
#1  0x00007fb4cbabab0f in copy_array_to_vbo_array.isra ()
   from /run/opengl-driver/lib/dri/i965_dri.so
#2  0x00007fb4cbabb3b7 in brw_prepare_vertices () from /run/opengl-driver/lib/dri/i965_dri.so
#3  0x00007fb4cbabb986 in brw_emit_vertices () from /run/opengl-driver/lib/dri/i965_dri.so
#4  0x00007fb4cbad13a1 in brw_upload_render_state ()
   from /run/opengl-driver/lib/dri/i965_dri.so
#5  0x00007fb4cbab9ce8 in brw_draw_prims () from /run/opengl-driver/lib/dri/i965_dri.so
#6  0x00007fb4cb8b5a9a in vbo_draw_arrays () from /run/opengl-driver/lib/dri/i965_dri.so
#7  0x00007fb4e43bf006 in lambdacubezmglzm0zi5zi2zi3zmIAoiOJ1mI2lDFzzf9HuJpO2_LambdaCubeziGLziBackend_renderSlot1_info ()
   from /nix/store/knad873vg45139r9mfy5zjnq7rz3kdlw-lambdacube-gl-0.5.2.3/lib/ghc-8.0.1/lambdacube-gl-0.5.2.3/libHSlambdacube-gl-0.5.2.3-IAoiOJ1mI2lDFzf9HuJpO2-ghc8.0.1.so
#8  0x00007fb49c055c70 in ?? ()
#9  0x0000000000000000 in ?? ()
(gdb) quit
A debugging session is active.
@deepfire
Copy link
Contributor Author

deepfire commented Mar 7, 2017

Note: it's a degenerate case, so it's likely running out of resources.

What is interesting, though, is that it only seems to crash from under intero -- it runs fine for a quite while when ran as a compiled binary..

@csabahruska
Copy link
Member

csabahruska commented Mar 7, 2017 •
edited
Loading

Does the compiled version crash at all?
I don't know how the interactive mode handles the threads and FFI.

@deepfire
Copy link
Contributor Author

deepfire commented Mar 7, 2017

I haven't seen the compiled version crash.

However, running it under control of halive still leads to a crash.

@csabahruska
Copy link
Member

is this similar to this?
http://stackoverflow.com/questions/34706215/program-crash-while-i-try-use-glfw-b-in-ghci

@deepfire
Copy link
Contributor Author

deepfire commented Mar 7, 2017

No, this one doesn't crash intero for me -- even if I change it to:

import Graphics.UI.GLFW as GLFW

main = do
  GLFW.init
  GLFW.terminate
  main

@csabahruska
Copy link
Member

what if you do something with gl? i.e.
bsl/GLFW-b#53

@deepfire
Copy link
Contributor Author

deepfire commented Mar 7, 2017

I have tried to stress that example as well, first by repeatedly running main and manually hitting M-<f4>, then by:

main :: IO ()
main = do
  GLFW.init >>= require "GLFW.initialize"
  window <- GLFW.createWindow 800 800 "EnvelopesGLFW.hs" Nothing Nothing >>= \ w ->
           case w of Just w -> return w; Nothing -> do GLFW.terminate; error "GLFW.createWindow"

  GLFW.makeContextCurrent (Just window)
  GLFW.swapInterval 1
  GL.clearColor $= Color4 0 0 0 1

  (width, height) <- GLFW.getFramebufferSize window
  GL.viewport $= (GL.Position 0 0, GL.Size (fromIntegral width) (fromIntegral height))
  GL.clear [ColorBuffer]
  GLFW.swapBuffers window
  GLFW.waitEvents

  GLFW.destroyWindow window
  GLFW.terminate
  main

..and yet it didn't manage to crash intero.

@csabahruska
Copy link
Member

In case of lambdacube, how many times do you execute those operations?

@deepfire
Copy link
Contributor Author

deepfire commented Mar 8, 2017

It was a stupidly tight loop, running at framerate frequency.

@deepfire
Copy link
Contributor Author

deepfire commented Mar 8, 2017

..at unconstrained framerate frequency, which meant it was running the FRP network & Lambdacube renderer as fast as possible -- sequentially, one after another.

@csabahruska
Copy link
Member

Can you count it?

@deepfire
Copy link
Contributor Author

deepfire commented Mar 8, 2017

Working on it -- in a roundabout way, though..

deepfire added a commit to deepfire/holotype that referenced this issue Mar 9, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
9ece927
deepfire added a commit to deepfire/holotype that referenced this issue Mar 9, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
691329d
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
2a5ff40
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
977c9df
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
e3544e1
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
872eec8
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
ba5e61a
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
ffd5910
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
45f05ed
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
3852aeb
deepfire added a commit to deepfire/holotype that referenced this issue Mar 10, 2017
@deepfire
Holostress: repro for lambdacube3d/lambdacube-gl#9
f8fa409
@deepfire
Copy link
Contributor Author

deepfire commented Mar 10, 2017 •
edited
Loading

@csabahruska, I have isolated a minimal testcase in:

New information:

  1. does crash both on an Intel and on a nVidia GPU
  2. does crash in compiled code! (see repro instructions at top of the file)

@deepfire
Copy link
Contributor Author

deepfire commented Mar 10, 2017 •
edited
Loading

Notably, this is a minimal testcase, which means that both:

        dGIC          ← GIC.Context <$> GI.newManagedPtr (F.castPtr $ GRC.unCairo dGRC) (return ())

..and..

        _ ← GIPC.createContext dGIC

are crucial for the repro.

This widens the scope of the question from just LambdaCube:

  1. it could be my incompetence in using pointer arithmetic (yet it only does crash after hundreds of iterations on an intel card in compiled code mode.. not sure what to make of it)
  2. it could be a problem in Graphics.Rendering.Cairo / GI.PangoCairo

@deepfire
Copy link
Contributor Author

Huh.. I guess I've lost the repro on my nVidia-based system -- that, after having developed the whole repro on it. And a reboot didn't change much - the nVidia repro is lost.

Yet on an intel laptop it still reliably produces this (compiled binary):

[nix-shell:~/src/mood]$ git log -n1
commit f8fa409193069085f74652ce0581ca8ea4c9f232
Author: Kosyrev Serge <[email protected]>
Date:   Fri Mar 10 04:55:02 2017  0300

    Holostress:  repro for https://github.com/lambdacube3d/lambdacube-gl/issues/9

[nix-shell:~/src/mood]$ ghc --make ./Holostress.hs
[1 of 1] Compiling Main             ( Holostress.hs, Holostress.o )
Linking Holostress ...

[nix-shell:~/src/mood]$ ./Holostress
-- allocating GPU pipeline (GL.allocRenderer)... 5.1ms
01234501234501234501234501234501234501234501234501234501234501234501234501234501234501234501234
50123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123
45012345012345012345012345012345012345012345012345012345012345012345012345012345012345012345012
...
3450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123450123Segmentation fault

@csabahruska
Copy link
Member

I wonder why would you upload the same geometry to the GPU in each frame? Why don't you reuse it? Of course the GPU will run out of memory sooner or later.

@deepfire
Copy link
Contributor Author

Could be so.. but why wouldn't LambdaCube tell me so? : -)

@csabahruska
Copy link
Member

That's a point! :) It should. But not implemented yet. I put that on the todo list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@deepfire @csabahruska