| Summary: | =sys-devel/gcc-8.2.0-r6 - kernel: traps: hlds_linux[6596] general protection ip:f7c825ba sp:ffbe8afc error:0 in libc-2.27.so | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | am1 <alexander.meinhardt+forum> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | hydrapolic, slyfox |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | rehlds hlds_linux file | ||
|
Description
am1
2019-02-26 09:19:23 UTC
Can you please provide more information on your 3rd-paty service? Doing a quick hlds_linux search gives me https://github.com/ValveSoftware/halflife, is that the case? Ideally how to reproduce so we can test on some other machine that works fine. Created attachment 566600 [details]
rehlds hlds_linux file
Sure i will, but need some help, because it's the first time i filled a bug report here and i'm really nooby with this. I attached the affected file but i'm not 100% sure it's the file itself than a depency behind. You're right about, that hlds_linux is Valve Halflife 1 (Counter-Strike 1.6 Dedicated Server), but we're not using the old outdated sources. Some developers redeveloped this under the pseudonym "ReHLDS" - https://github.com/dreamstalker/rehlds The package we're using you can find here http://nexus.rehlds.org/nexus/content/repositories/rehlds-dev/rehlds/rehlds/3.4.0.668-dev/ but this may not work at all, because some other files are missing as well. Not that easy to provide a working setup to test on other machines. I can test things but need some briefing how to do, especially debugging!? Thank you for the bug report! > Tried using sandbox-2.15 by unmasking (thread https://forums.gentoo.org/viewtopic-t-1090722-start-0.html) doesn't fix this issue with "general protection" at all. I think it's an unrelated bug. It caused gcc itself (or ld) to crash under sandbox. You have an external binary crash running outside sandbox. Is it enough for you to start a binary to make it crash? Or you also need to connect clients to it? Can you also provide a backtrace of the crash as described in https://wiki.gentoo.org/wiki/Debugging ? You will need to build glibc (and perhaps libtool and other deps) with debugging enabled, enable core dumps and run core dump against 'gdb your-binary core.file'. It's OK if your binary has no symbols. @Sergei Trofimovich Sorry for the delay, but i wasn't able to reproduce via backtracing, because there are a huge plugins involved. Anyway, this seems fixed with the release of =sys-devel/gcc-8.3.0-r1! So we can close this bugreport without any further actions. Thanks! |
