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.
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.
3 Comments:
RobZed, are you the developer of LWC?
A long time ago I helped. LWC is obsolete now though. The direct replacement is http://trixology.com/weathercat/ and is made by Stu.
Thank you for the information, Rob. All the best in life and endeavours.
Post a Comment
<< Home