Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Without seeing the rest of your program, it's hard to say why it's segfaulting. It sounds timing-related. Here's a few things you can try:</p> <ul> <li><p>Put breakpoints in the constructors of your Engine class, Input class, (any other involved classes,) and the callback-setting code. That will tell you if the callbacks are registering before the singletons they use construct. Note that breakpoints might throw off your program's timing, so if one class hits first, you can disable that breakpoint and rerun. Try this multiple times to check the results are consistent.</p></li> <li><p>Is there a reason you can't try the change to pointers instead of references (like the "fiasco" mentions)?</p></li> </ul> <p>(Your update while I was writing this makes this part not-so-useful since the callstack shows it's not in a constructor. )This sounds like the callbacks are registering during construction of some class. If that's the case:</p> <ul> <li><p>Can you move the registration calls so they happen under main()? That ought to get you past initializations.</p></li> <li><p>Split up the class construction into two phases: the normal constructor, and an init() function. Put the critical code inside init(), and call that after <em>everybody</em> has finished constructing.</p></li> </ul> <p>You could also prevent the callbacks from happening until later. If you can't move the callback registration to a later time in your game's startup, you could put flags so they don't do anything until a "safe" time. Adjusting <em>when</em> this flag enables could let you see "how late" is "late enough". The extra if() overhead is better than a crash. :)</p> <pre><code>volatile bool s_bCallbackSafe = false; // set this at some point in your game/app void GLFWCALL procMouseButton(int button, int action) { if (s_bCallbackSafe) Input::instance().processMouseButton(button, action); // doesn't do anything yet } </code></pre>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COShould have mentioned that none of my singletons have normal constructors. They are all initialized as `Singleton::instance().initialize()`. Pointers did not make a difference. The callbacks are working fine. For example, when I register the mousepos callback, it is called immediately right after. The segfault occurs when pushing to the vector, which must have been working fine for `StartupState` to call `Input::Initialize()`. I know I can fix it by moving around stuff, i.e. not using singletons, etc., but what really disturbs me is why this problem is occuring.
      singulars
    2. CODoes commenting out the line of code in the callback make any difference? That might narrow it down to something about simply calling `Input:: processMouseButton()` even when it's empty. Note that callbacks can run from a separate thread even if your app is single-threaded. You can also try the `push_back`, then `Input::processMouseButton`, then `push_back` again to see if the in-between call smurfs it. Sorry I don't have a solution, just bug-hunt ideas that might shine a light on the issue.
      singulars
    3. COCommenting out the inside of any two callback functions fixes it. I really suspect something going wrong in memory because of the glfw functions. Commenting out functions that absolutely do nothing fixes it! I might as well compress it down to a small program that reproduces the bug and submit to the GLFW folks. Thanks for trying though, I may yet find the solution.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload