[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #7 from Julian Seward --- (In reply to infinity0 from comment #5) Greetings, Rustacean::infinity0. Is this bug still a problem for the Rust devs? If yes, are there up to date STRs? On the whole I am unhappy when Valgrind fails, for unclear reasons, to run a program that works natively. So if there's an easy fix, it would be nice to find it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 Philippe Waroquiers changed: What|Removed |Added CC||philippe.waroquiers@skynet. ||be --- Comment #6 from Philippe Waroquiers --- Seeing the first 2 lines of output: ==6449== Can't extend stack to 0x4bb9880 during signal delivery for thread 2: ==6449== no stack segment it might be worth trying with --vex-iropt-register-updates=allregs-at-each-insn just in case your test case does special things with signals. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #5 from infini...@pwned.gg --- Well, I had already tried setting --main-stacksize (as the error message suggests) very high all the way until other tests started failing because the "stack was too big", and the segfault issue persisted. I know that this flag doesn't change the stack size of new threads, however I read somewhere else that the latter is outside of valgrind's control so that's why there is no such flag - but then this also implies that shouldn't be the cause of this issue. (Or is this wrong? I'm just repeating what I remember reading, I don't really understand valgrind.) Does your theory explain why everything's OK on amd64, and is also OK on i686 when we statically link the test executable (the current "fix" commited to rust)? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #4 from Tom Hughes --- At least I thought it did, because I remember it being discussed recently, bit I can't find it right now... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #3 from Tom Hughes --- What you're missing is that valgrind imposes it's own limit of 8Mb on the stack, which you have clearly hit given the size it reported. Just looking at the memory map won't help you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 --- Comment #2 from infini...@pwned.gg --- We don't think that's the real reason. I don't know how to analyse such things but another Debian maintainer looked through the proc-mem map that I linked above, and had this to say: 15:48:15 infinity0: it seems to me it still has some space to grow the stack in slot 26, even though I don't understand why it's trying to do it there 15:49:41 infinity0: I think valgrind is getting to confuse the same way and won't let the stack grow there -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359705] memcheck causes segfault on a dynamically-linked test from rustlang's test suite on i686
https://bugs.kde.org/show_bug.cgi?id=359705 Tom Hughes changed: What|Removed |Added CC||t...@compton.nu --- Comment #1 from Tom Hughes --- Hasn't it told you exactly what cause the fault? You ran out of stack space... -- You are receiving this mail because: You are watching all bug changes.
