Input_server crashes on restart

[hitech]

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...

[hitech]

Crash report of the input_server

[waddlesplash]

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.)

[hitech]

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?

[waddlesplash]

LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=g [app] is the normal way.

[diver]

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

[waddlesplash]

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.

[X512]

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.