Monday, May 26, 2014

I hate random crashing, especially Seg Faults :-(

I hate seg faults. Luckily this one was easy enough to track down.

Basically we had migrated a bunch of debug calls to a unified interface (so that things like Android targets could use specific calls rather than the generic mixture of std::cout and printf which go nowhere(?)). Printf-style formatting was useful, which lead us to using vsprintf.

Only problem: buffer was a fixed 256 bytes long. A really dislike C-style code for bugs like this. (Our project is meant to be 'pure C++').

When I introduced Lua stack traces, guess what get blown through?

So, initially, I allocated the buffer to be 20000 on the heap (rather than the stack). This, of course, is a hack that might come back to bite me.

So I looked at vsnprintf ... which is supported on a bunch of targets - Microsoft and Apple mention it. So does the Linux documentation. Also C++11 and C99. Don't quote me on this however. Also - do all targets implementations zero terminate corrrectly if they run out of buffer space?

Really, what I want is a self-allocating version. Allocating a huge number - even with a limited function is sort of rubbish. vasprintf - which is supplied by glibc/Linux/Unix/MacOSX looks like the way to go. Problem is which platforms is this supported on? And does this mean we will end up wasting time by implementing our own. There are a couple of forums where people have given ideas on this - but still, it's a couple of hours finishing and debugging that is nothing to do with actually writing your application.

I feel like I've spent enough time on this already - time where I could have been working on the actual game. All to avoid a stupid inconvient seg fault - now or in the future. Which is basically due to the naive C string container.


Gulpman Lua error - with and without traceback

I have done the Lua traceback changes for all calls from our C++ helper class (dofile, docall, etc.) a few days ago ... what is the difference we are likely to see?

The ideas is basically that you should be able to trace down the error easier. These don't show a lot of extra detail, but I'm sure you'll get the idea.

With traceback generated by our helper function

ERROR STRING

error loading module 'controllers/DemoController' from file '/Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/controllers/DemoController.lua':
    ...Gulpman/data/data/scripts/controllers/DemoController.lua:57: syntax error near 'a'
stack traceback:
    [C]: in ?
    [C]: in function 'require'
    .../iPhone/gulpman_clone/Gulpman/data/data/scripts/main.lua:27: in main chunk

PRINTED BY GULPMAN

Lua error: error loading module 'controllers/DemoController' from file '/Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/controllers/DemoController.lua':
    ...Gulpman/data/data/scripts/controllers/DemoController.lua:57: syntax error near 'a'
stack traceback:
    [C]: in ?
    [C]: in function 'require'
    .../iPhone/gulpman_clone/Gulpman/data/data/scripts/main.lua:27: in main chunk in /Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/main.lua
Failed to load main.lua

Standard Error

ERROR STRING

error loading module 'controllers/DemoController' from file '/Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/controllers/DemoController.lua':
    ...Gulpman/data/data/scripts/controllers/DemoController.lua:57: syntax error near 'a'

PRINTED BY GULPMAN

Lua error: error loading module 'controllers/DemoController' from file '/Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/controllers/DemoController.lua':
    ...Gulpman/data/data/scripts/controllers/DemoController.lua:57: syntax error near 'a' in /Users/rob/Current_Projects/iPhone/gulpman_clone/Gulpman/data/data/scripts/main.lua
Failed to load main.lua



Newer›  ‹Older