Hello, I've been writing an app that uses warp.
Recently I started having very weird issues. The program will segfault seemingly randomly.
When I say randomly I mean the segfaults are consistent for a given build but seem to be move around as I modify / comment out some code and recompile.
I had the issue for a while and the debugger pointed the crash to Serde de serializing a struct.
Now I have it occur inside of warp just by calling an endpoint.
See the error given by the debugger.
I am not able to pinpoint the actual cause nor give a minimum reproducible code since it seems to be very tied to the actual project as I said.
The very weird thing is that when compiling as a release without changing the code at all the segfaults completely vanish.
I am just at a loss at what could be the issue here, to me it really seems like something went very wrong at the compilation time but I don't know enough about the inner workings to be sure this is it and make a bug report.
I am able to provide anything else that might be of use (gdb, ...).
Please help 
Update 1:
I tested compiling and executing the same program on another computer with the same results.
Update 2:
The program prints the following which I am not sure I trust is the case.
thread 'tokio-runtime-worker' has overflowed its stack
fatal runtime error: stack overflow
Screenshots are hard to read. Could you please post the backtrace as text inside ``` fences?
The stack overflow would be a concerning error. I'm not sure what is supposedly untrustworthy about it.
Do you mean using --release
makes the executable stop crashing? Compiler optimizations can remove (or reduce) stack usage by inlining function calls and unrolling recursive calls. And in general, can use fewer stack allocations. It seems probable that debug builds could hit the stack size limit. If that's the case, maybe adding some optimizations to your debug profile is "good enough" as a workaround?
[profile.dev]
opt-level = 1
1 Like
Thanks for your reply.
You seem to be right, and this is corroborated with threads I ended up finding about stack overflow that can happen "easily" with debug builds. Since warp relies a lot on functions call and I had all my routes declared in a single function.
I ended up discovering that removing any route was resolving the issue. This seems to indicate that in fact there is a real stack overflow.
I was thrown off by the debugger message about what seemed like memory errors and assumed the stack overflow was just a default error message that would occur when the thread crashes (bad assumption). I was too focused on this and the fact that the exact point where the code would crash was moving around when changing code (which is also explained by a stack overflow.
After refactoring the code to split function calls the issue seems to be resolved.
Thank you for making me snap out of it 