Closed kamocat closed 4 years ago
I don't have an SDcard Feather yet, but I'll be able to debug it Friday. In the meantime, a few things I noticed:
String
using a char*
here:
https://github.com/kamocat/plog/blob/07716e54da138f9b6f6dd985d94d12d4d38cd002/include/plog/Formatters/MessageOnlyFormatter.h#L17 Though the String
constructor should only be called after getMessage
completes, I still suspect this is the issue.getMessage
may also be causing issues. The static_cast<util::nostringstream>
constructs a new util::nostringstream
using m_message
as the constructor parameter, which may or may not lead to dangling pointers (util::nostringstream
may decide to make a copy, or may not). What might work better is a const_cast
on this
, which just cheats away the const qualifier on m_message
:
virtual const util::nchar* getMessage() const
{MARK;
return static_cast<const util::nchar*>(
const_cast<Record*>(this)->m_message.buf()
);
}
I'll let you deal with this one. I made a simpler file appender - it works well enough for me.
I opened a pull request to fix the second point, and I'll look into the hardfault.
I found one issue. You construct a obufstream
here with no pointer to stream into: https://github.com/kamocat/plog/blob/a5d6fb133aafc2ec5fd309590c1d9339c4c8e5ce/include/plog/Appenders/RollingFileAppender.h#L86-L89 Without a parameter, obufstream
defaults to a null pointer that can be changed later with obufstream::init
. Since you do not change this value, the code immediately hard faults after dereferencing the null pointer.
Thanks for finding that! I searched the rest of the library, and this appears to be the only improperly initialized nostringstream.
All for formatters work fine with the SerialAppender, but when I use the RollingFileAppender I run into trouble.
The RollingFileAppender hiccups when I call a formatter https://github.com/kamocat/plog/blob/07716e54da138f9b6f6dd985d94d12d4d38cd002/include/plog/Appenders/RollingFileAppender.h#L36-L37
because the formatter hard-faults on line 17 https://github.com/kamocat/plog/blob/07716e54da138f9b6f6dd985d94d12d4d38cd002/include/plog/Formatters/MessageOnlyFormatter.h#L15-L22
Somehow, we're not even reaching record.getMessage() https://github.com/kamocat/plog/blob/07716e54da138f9b6f6dd985d94d12d4d38cd002/include/plog/Record.h#L145-L150
I'm finding that these MARK statements don't go quite fine-grained enough for this problem. A hardware debugger would be invaluable.