#2076 Binary monitor crash on simple memset command (Linux)

[Brian Holdsworth]

Hi. I'm having a problem with the binary monitor. This use to work fine in v3.6. Does not work in v3.8.

For this issue, I built the latest release from svn (r45348) for Linux x86_64 and using the SDL UI. I expect the problem is easily recreated on any recent Linux build.

To cause the binary monitor to crash, start x128 with the binary monitor enabled on default port 6502. Use cat and nc commands from the CLI, as shown below, to send the following 21 bytes to the binary monitor:
00000000: 0202 0a00 0000 cdab 3412 0200 9b00 9c00
00000010: 0000 0004 00

I used this command: cat mon.hex | nc --close localhost 6502

The result is a core dump in vice. It does show several vice_network_xxx: internal error errors just before crashing, but no real hint of the cause.

Complete vice log file is attached.

[Querino]

doesn't crash on windows, but i also get the log entries...

Error - vice_network_send: internal error
Error - vice_network_send: internal error
Error - vice_network_send: internal error
monitor_binary_receive(): vice_network_receive() returned -1, breaking connection

but the vice_network_receive() returned -1, breaking connection i also get with older VICE versions, so makes me wonder whether this actually really worked.

[Brian Holdsworth]

Interesting.

The 21-byte command is trying to set the values at $9b/$9c. If you can look at those addresses in the debug monitor before/after the command, it should be obvious if the command did anything.

[gpz]

it doesn't crash for me in linux (using GTK build though) - but 9b/9c are not being modified either :) Also tried in x64sc - exactly the same. Oh and i also get those errors.

[gpz]

part1: use something like cat mon.hex | nc -q 5 localhost 6502 | hex and the send errors go away (these are about the reply the command sends)

[gpz]

part2: please try r45354 - it works for me. i don't know why - it shouldn't change anything :)

(maybe you need a clean rebuild?)

[Querino]

yeah, i tested another netcat, so cat mon.hex | netcat -x -o test --close localhost 6502 gives no error, but i also don't see 9b/9c changed. but this was not different in VICE 3.6, was it? the output in the file test is

00000000  30 32 30 32  20 30 61 30  30 20 30 30  30 30 20 63  0202 0a00 0000 c
00000010  64 61 62 20  33 34 31 32  20 30 32 30  30 20 39 62  dab 3412 0200 9b
00000020  30 30 20 39  63 30 30 20  30 30 30 30  20 30 30 30  00 9c00 0000 000
00000030  34 20 30 30  0D 0A 0D 0A                            4 00.... 

that seems to be fine i think.

[gpz]

It changed 9b/9c for me... but only after i made this "fix" and recompiled - no idea why

[Brian Holdsworth]

I made a fresh build using the tar ball for r45354. No real difference. Still does a core dump for me. The error messages that are output are somewhat different with the new version, as shown below.

Error - vice_network_send: internal error (ret:-1 buffer_length:12 errno:32 - Broken pipe)
Error - vice_network_send: internal error (ret:-1 buffer_length:42 errno:32 - Broken pipe)
Error - vice_network_send: internal error (ret:-1 buffer_length:12 errno:32 - Broken pipe)
Error - vice_network_send: internal error (ret:-1 buffer_length:2 errno:32 - Broken pipe)
Error - vice_network_send: internal error (ret:-1 buffer_length:12 errno:32 - Broken pipe)
monitor_binary_receive(): vice_network_receive() returned 0, breaking connection
Segmentation fault (core dumped)

I also have not seen any difference with using other arguments to nc. My use case is to just send the memory set command and immediately close the socket. I don't have much/any need to process the response.

In case it is relevant, here is the config options I am using in my builds:

  ./configure \
    --enable-sdl2ui \
    --without-pulse \
    --without-oss \
    --with-vorbis \
    --disable-pdf-docs \
    --disable-html-docs \
    --libdir=/usr/lib \
    --prefix=/usr

[gpz]

really weird. The send errors are expected (if not waiting for the response). And the receive error just indicates that the connection was dropped (also expected).

shrug

[Querino]

still does not change 9b/9c for me, neither my own compile nor the one from github. though there is no -qoption available here in netcat.

but... just to make really sure i did understand properly: 9b/9c is the memory in the emulator, right? so after doing the remote commands i should see the changes if is use the "standard monitor" and do something like m b9?

[gpz]

yes, what i do is

> 9b 12 34

then run the command with nc, and to check

m 9b

[Querino]

ok, i can make it working on windows, sort of.
if the mon.hex is binary, i can use something like

netcat -o output localhost 6502 < mon.hex > received
or (if you have the tools) the mon.hex can be ascii
cat mon.hex | xxd -r -p | netcat -o output localhost 6502 > received

but i need to terminate netcat (or whatever) manually, i cannot use -close, this will send only it looks, and that won't work.

//edit: the best solution i found now is nc64 instead of netcat:
cat mon.hex | xxd -r -p | nc64 -w 1 -o output localhost 6502 > received
here indeed the -w 1 works, and will terminate itself.

[Querino]

so it seems the different netcat implementations work differently? or the OS itself handles it differently? maybe my netcat expects a binary input?

[gpz]

this ncat is a different program ... it doesn't work for me at all in linux (the binary that is, i didn't compile from source yet)

[Brian Holdsworth]

On Arch Linux, the repository has two differnet netcat's - gnu-netcat and openbsd-netcat. They use different arguments but seem to be the same in basic functionality. I am always using 'cat' with a binary file containing the 21 bytes, and this seems to work same with either 'nc'.

ALSO, I don't know much about auto-tools; is there a simple way to make a debug build that can give me a useful stack dump from the core file? All I get from the current core file is the raw address of the crash and no symbol info.

[gpz]

configure with --enable-debug should enable this

[Querino]

so where is a proper nc for windows? :)