Opened 5 years ago
Last modified 4 years ago
#15126 new bug
Input_server crashes on restart
Reported by: | hitech | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/input_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86-64 |
Description
While developing an input_server add-on, I had to restart the server quite a few times, with "input_server -q" from CLI. Once in every three restarts I was thrown into KDL, with the report attached.
This behavior was observed at least from June 13, 2019, and is persistent as of rev 53209. My platform is x64, I have no idea if this behavior can be reproduced on x86, therefore marking the platform as x64 only.
If I "continued", mouse was working, but keyboard was not.
A quick search for the functions in the report didn't return any bugs that look similar...
Attachments (1)
Change History (7)
by , 5 years ago
Attachment: | input_server-3617-debug-28-06-2019-01-36-16.report added |
---|
comment:1 by , 5 years ago
Appears to be a double-free assertion in the allocator. Can you retest this, running input_server with the guarded heap? (Dunno precisely how to do that in this scenario.)
comment:2 by , 5 years ago
Possibly, blacklist input_server with adding into non-packaged FS the "input_server" symlink to a script that runs input_server with guarded heap? What is the way to run a program with the guarded heap? Will the suggested way work?
comment:5 by , 4 years ago
I'm not sure. There is a very strange stack trace:
state: Debugged Frame IP Function Name ----------------------------------------------- 00000000 0x2e81755e3f _kern_exit_team + 0x7 Disassembly: _kern_exit_team: 0x0000002e81755e38: 48c7c026000000 mov $0x26, %rax 0x0000002e81755e3f: 0f05 syscall <-- 0x7f4a5717e890 0x2e817eada0 getsubopt + 0
I saw this on one of the Web+ tickets recently, maybe it's related.
comment:6 by , 4 years ago
I'm not sure. There is a very strange stack trace:
This is probably debugger bug that wrong thread is sometimes being debugged. I experience it sometimes. Note that state is "Debugged", not "Exception".
Crash report of the input_server