Attempting to deserialize a very large element results in the thread overflowing its stack

[indiv0]

Hello, me again!

I'm attempting to deserialize a very large instance of an element, and it's resulting in the following error:

    Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/wolfram_alpha-04600d635340b2d6

running 21 tests
test model::tests::test_error_deserializer ... ok
test model::tests::test_didyoumean_deserializer ... ok
test model::tests::test_didyoumeans_deserializer ... ok
test model::tests::test_definitions_deserializer ... ok
test model::tests::test_notes_deserializer ... ok
test model::tests::test_plaintext_deserializer ... ok
test model::tests::test_img_deserializer ... ok
test model::tests::test_infos_deserializer ... ok
test model::tests::test_languagemsg_deserializer ... ok

thread 'model::tests::test_plaintext_too_large_deserializer' has overflowed its stack
fatal runtime error: stack overflow
error: process didn't exit successfully: `/home/indiv0/src/rust/wolfram-alpha-rs/target/debug/deps/wolfram_alpha-04600d635340b2d6` (signal: 6, SIGABRT: process abort signal)

To learn more, run the command again with --verbose.

The element type is defined as:

pub type Plaintext = String;

The example text can be found here.

Is this expected?

[oli-obk]

Yea stackoverflows are hard. I suggest you enable optimizations for your tests, then the stackoverflows should only happen when doing really deeply nested deserialization. I'll add some checks to ensure it results in a readable error message instead of a stackoverflow

[indiv0]

OK I'll do that for my tests, the only problem is the way I found out about this is that it happened during normal usage of the library (i.e. outside of tests), so I was hoping for a way to make it not crash in the long term. For now I'm using larger stack sizes on the threads as a bandaid.