Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack corruption with big write #480

Closed
Sumenia opened this issue Mar 2, 2017 · 6 comments
Closed

stack corruption with big write #480

Sumenia opened this issue Mar 2, 2017 · 6 comments

Comments

@Sumenia
Copy link

Sumenia commented Mar 2, 2017

I'm getting a libc: stack corruption detected when using MemoryWriter::write("{}", msg) with a big (> 5k) string as msg.

This is happening on Android (Nougat).

any idea ?

@vitaut
Copy link
Contributor

vitaut commented Mar 3, 2017

Could you post a reproducible example?

@Sumenia
Copy link
Author

Sumenia commented Mar 3, 2017

Ok I ran some experiments and found out that this code reproduces the problem :

   std::string msg;

    for (uint32_t i = 0; i < 5420; ++i) {
        msg += "s";
    }

    fmt::MemoryWriter writer;
    writer.clear();
    writer << "info";
    writer << msg;

This depends on the calling context (either if this code is split between functions or not, etc).

The writer << "info"; is important as the code works fine without it.

The stack corruption only appears on the next function return.

edit : forgot to mention that this problem doesn't occur on Linux

@vitaut
Copy link
Contributor

vitaut commented Mar 3, 2017

Does it happen on the latest master?

@Quentin01
Copy link
Contributor

Not the last commit on master but the previous one 789ebea8637cce4a7deef.

@vitaut
Copy link
Contributor

vitaut commented Mar 8, 2017

I've traced your example code in the debugger and don't see anything that might cause stack corruption. However, note that MemoryWriter uses an inline buffer of size 500 chars, which can cause problems if the stack size limit is small. If this is the case you can use StringWriter instead.

@vitaut vitaut closed this as completed Mar 8, 2017
vitaut pushed a commit that referenced this issue Apr 8, 2017
Fixes #491 (and probably #480) Before, the put-area of the custom streambuf
implementation was (sometimes) incorrectly extended beyond the writeable buffer.
The new implementation is in some cases not as efficient as the old, but avoids
to write into uninitialized memory.
@vitaut
Copy link
Contributor

vitaut commented Apr 8, 2017

Might be related to #491 which has just been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants