Opened 13 months ago

Last modified 2 weeks 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


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) (15.2 KB ) - added by hitech 13 months ago.
Crash report of the input_server

Download all attachments as: .zip

Change History (7)

by hitech, 13 months ago

Crash report of the input_server

comment:1 by waddlesplash, 13 months 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 hitech, 12 months 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:3 by waddlesplash, 12 months ago MALLOC_DEBUG=g [app] is the normal way.

comment:4 by diver, 2 weeks ago

Since we moved away from rpmalloc this one is probably fixed?

comment:5 by waddlesplash, 2 weeks ago

I'm not sure. There is a very strange stack trace:

        state: Debugged
	        Frame       IP          Function Name
	        00000000    0x2e81755e3f    _kern_exit_team + 0x7
	                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 X512, 2 weeks 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".

Last edited 2 weeks ago by X512 (previous) (diff)
Note: See TracTickets for help on using tickets.