DDTTYLogger can cause a crash if the log message is too big for the stack

[joein3d]

At about line 1094:

char msg[msgLen + 1];

[logMsg getCString:msg maxLength:(msgLen + 1) encoding:NSUTF8StringEncoding];

Was crashing for a very large log message. I assume this is because it was too big for the stack. I was able to fix by malloc'ing the msg instead and freeing after it's used. Not sure if this is the best fix due to potential performance implications.

[robbiehanson]

We used to use [logMsg UTF8String], which internally does a malloc, and essentially returns an autoreleased char array.

We switched to the current stack-based technique because it was so much faster. Looks like there should be an added check on the msgLen. And if too big for the stack, then we'll go to the heap.

Any idea on what that max msgLen should be for the stack?

Robbie Hanson
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, May 30, 2012 at 2:53 PM, joein3d wrote:

At about line 1094:

char msg[msgLen + 1];

[logMsg getCString:msg maxLength:(msgLen + 1) encoding:NSUTF8StringEncoding];

Was crashing for a very large log message. I assume this is because it was too big for the stack. I was able to fix by malloc'ing the msg instead and freeing after it's used. Not sure if this is the best fix due to potential performance implications.

---

Reply to this email directly or view it on GitHub:
#38

[joein3d]

According to this doc

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html

Stack size on secondary threads is 512 KB. I verified this by calling [[NSThread currentThread] stackSize];

However, this doesn't really tell us how much stack space is still available. My guess would be to make the limit something much smaller than that, but still much larger than most logs. Maybe 4KB? Feels odd to just pick a number out of the air rather than know the actual available space, but I couldn't find a fast/easy way to calculate it.

[robbiehanson]

My guess would be to make the limit something much smaller than that, but still much larger than most logs

I agree. And 4K sounds like a reasonable size.