From: Randy MacLeod <randy.macleod@windriver.com>
To: Yash Shinde <Yash.Shinde@windriver.com>,
openembedded-core@lists.openembedded.org
Cc: Naveen.Gowda@windriver.com, Sundeep.Kokkonda@windriver.com
Subject: Re: [PATCH] cargo: Increase RUST_MIN_STACK size to avoid SIGSEGV in DEBUG builds only.
Date: Thu, 31 Oct 2024 10:02:56 -0400 [thread overview]
Message-ID: <35d5f2ec-4281-4be1-8040-829dbbdc0d58@windriver.com> (raw)
In-Reply-To: <7a5cd559-7db3-461d-bef6-10e4545e1b8a@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]
On 2024-10-31 5:35 a.m., Yash Shinde wrote:
>
> On 30-10-2024 19:54, Randy MacLeod wrote:
>> On 2024-10-30 7:16 a.m., Yash.Shinde@windriver.com wrote:
>>> From: Yash Shinde<Yash.Shinde@windriver.com>
>>>
>>> For some Rust crates, like building p384 in DEBUG mode, a SIGSEGV
>>> is encountered as follows:
>>>
>>> note: rustc unexpectedly overflowed its stack! this is a bug
>>> note: maximum backtrace depth reached, frames may have been lost
>>> note: we would appreciate a report
>>> athttps://github.com/rust-lang/rust
>>> note: backtrace dumped due to SIGSEGV! resuming signal
>>> error: could not compile `p384` (lib)
>>>
>>> WARNING: Backtrace (BB generated script):
>>> #1: oe_cargo_build,
>>> /home/poky/build/tmp/work/core2-32-wrs-linux/cargo/1.79.0/temp/run.do_compile.3262358,
>>> line 193
>>> #2: cargo_do_compile,
>>> /home/poky/build/tmp/work/core2-32-wrs-linux/cargo/1.79.0/temp/run.do_compile.3262358,
>>> line 165
>>> #3: do_compile,
>>> /home/poky/build/tmp/work/core2-32-wrs-linux/cargo/1.79.0/temp/run.do_compile.3262358,
>>> line 160
>>> #4: main,
>>> /home/poky/build/tmp/work/core2-32-wrs-linux/cargo/1.79.0/temp/run.do_compile.3262358,
>>> line 206
>>>
>>> Setting RUST_MIN_STACK to 8MB conditionally for DEBUG builds only
>>> handles
>>> the stack overflow and SIGSEGV.
>>
>> s/to 8MB/from 2MB to 8MB/
>>
>> Best to explain what the current default value in your commit log in
>> case the rust devs increase the limit some day.
>>
>> From:
>> rust.git on 🦀 v1.80.0
>> ❯ grep -C 1 DEFAULT_MIN_ST library/std/src/sys/pal/unix/thread.rs
>> #[cfg(not(any(target_os = "l4re", target_os = "vxworks", target_os =
>> "espidf")))]
>> pub const DEFAULT_MIN_STACK_SIZE: usize = 2 * 1024 * 1024;
>> #[cfg(target_os = "l4re")]
>> pub const DEFAULT_MIN_STACK_SIZE: usize = 1024 * 1024;
>> #[cfg(target_os = "vxworks")]
>> pub const DEFAULT_MIN_STACK_SIZE: usize = 256 * 1024;
>> #[cfg(target_os = "espidf")]
>> pub const DEFAULT_MIN_STACK_SIZE: usize = 0; // 0 indicates that the
>> stack size configured in the ESP-IDF menuconfig system should be used
>>
>>> References:https://github.com/esp-rs/rust/issues/214
>>> https://github.com/rust-lang/rust/issues/122357
>>> https://github.com/rust-lang/rust/pull/122847#issue-2201254359
>>> https://github.com/rust-lang/rust/pull/122847/commits
>> Is there an issue open for the p384 crate to reconsider their stack
>> abuse?
>>
>> If so, please include that link. If not, create one and link that.
>>
>>
>> Thanks Yashe,
>>
>> ../Randy
>>
> The second issue mentioned in the references is still open but there
> aren't any recent updates.
> Also, Sundeep had reported the same issue in rust and llvm before:
>
> https://github.com/rust-lang/rust/issues/113612 (closed as not planned)
>
> https://github.com/llvm/llvm-project/issues/76920 (open, but again
> points to https://github.com/rust-lang/rust/issues/122357)
>
> Let me know, if you want me to send a v2?
We discussed this issue and agreed that since it doesn't affect YP AB
since there are no DEBUG builds done there
and more importantly since it's really a work-around rather than a fix,
we'll continue to work with upstream p384
crate owners to resolve the issue. Forcing users to change the stack
size, even for debug builds, is not a good policy
and hopefully some of the code-generation tools that are inputs to p384
can be adjusted to reduce stack usage.
../Randy
>
> Regards,
> Yash
>
--
# Randy MacLeod
# Wind River Linux
[-- Attachment #2: Type: text/html, Size: 6976 bytes --]
next prev parent reply other threads:[~2024-10-31 14:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 11:16 [PATCH] cargo: Increase RUST_MIN_STACK size to avoid SIGSEGV in DEBUG builds only Yash.Shinde
2024-10-30 11:20 ` Yash Shinde
2024-10-30 14:24 ` Randy MacLeod
2024-10-31 9:35 ` Yash Shinde
2024-10-31 14:02 ` Randy MacLeod [this message]
2024-11-14 11:02 ` Yash Shinde
2024-11-14 12:01 ` [OE-core] " Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35d5f2ec-4281-4be1-8040-829dbbdc0d58@windriver.com \
--to=randy.macleod@windriver.com \
--cc=Naveen.Gowda@windriver.com \
--cc=Sundeep.Kokkonda@windriver.com \
--cc=Yash.Shinde@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.