Problems with socat

[Rick Payne]

Trying to characterise some performance stuff, I thought I'd run socat
under OSv however it panics:

$ sudo scripts/run.py -n -e 'socat tcp4-listen:6971 open:/dev/null'OSv
v0.55.0
eth0: 192.168.122.76
Booted up in 3245.70 ms
Cmdline: socat tcp4-listen:6971 open:/dev/null
Assertion failed: type == SOCK_STREAM (libc/af_local.cc:
socketpair_af_local: 101)

[backtrace]
0x00000000402228ae <abort(char const*, ...)+280>
0x0000000040222917 <__assert_fail+64>
0x00000000406fb1d0 <socketpair_af_local+61>
0x0000000040246c37 <socketpair+95>
0x0000100000034587 <???+214407>
0x657473696c2d346f <???+1814901871>

The particular function in socat which triggers this is:

static int diag_sock_pair(void) {
int handlersocks[2];

if (socketpair(AF_UNIX, SOCK_DGRAM, 0, handlersocks) < 0) {
diag_sock_send = -1;
diag_sock_recv = -1;
return -1;
}
diag_sock_send = handlersocks[1];
diag_sock_recv = handlersocks[0];
return 0;
}

And in OSv:

#5 0x00000000406fb1d1 in socketpair_af_local (type=2, proto=0,
sv=0x200000700b20) at libc/af_local.cc:101
101 assert(type == SOCK_STREAM);

Not sure why this restriction exists, and I've changed my local socat
to use SOCK_STREAM - but just thought we should note a difference
between linux and OSv here...

Rick

[Dor Laor]

Best is to put a breakpoint and start single stepping and read

those variable values

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/f604ee0d7c79713f24744c47903f5e5515bfbb3f.camel%40rossfell.co.uk.

[Rick Payne]

Thanks, but the question was more 'why does the OSv socketpair() only
support SOCK_STREAM, and not SOCK_DGRAM?'. I guess there has to be a
reason why that decision was made.

As another datapoint, I removed the assert in OSv and things 'worked'
(though I can't tell if that was luck or because that code wasn't
really exercised).

Rick

[Pekka Enberg]

Hi Rick,

On Thu, Jul 23, 2020 at 4:34 AM Rick Payne <ri...@rossfell.co.uk> wrote:

Thanks, but the question was more 'why does the OSv socketpair() only
support SOCK_STREAM, and not SOCK_DGRAM?'. I guess there has to be a
reason why that decision was made.

I doubt there's any technical reason. We likely just did not get to implementing it.

- Pekka 

[Nadav Har'El]

On Thu, Jul 23, 2020 at 3:57 AM Rick Payne <ri...@rossfell.co.uk> wrote:

Trying to characterise some performance stuff, I thought I'd run socat
under OSv however it panics:

$ sudo scripts/run.py -n -e 'socat tcp4-listen:6971 open:/dev/null'OSv
v0.55.0
eth0: 192.168.122.76
Booted up in 3245.70 ms
Cmdline: socat tcp4-listen:6971 open:/dev/null
Assertion failed: type == SOCK_STREAM (libc/af_local.cc:
socketpair_af_local: 101)

We implemented AF_LOCAL (UNIX-domain, local, sockets)  very early in OSv's development (2013), and at the time implemented only the part we needed - stream sockets. Unfortunately we never got around to completing the datagram sockets :-(

It should be easy to implement datagram sockets, while leaving out some more esoteric features like ancillary messages, like passing file descriptors - which aren't useful to single-process application in any case.

In any case, the assert() there is obviously not a great thing to do, both because it crashes the node and because a user seeing this would not even know that this is about an unimplemented feature. What we usually did in later code was to print a debugging message about an unimplemented feature, and then return a failure with errno to the caller. We have useful macros like NO_SYS for this in <osv/stubbing.hh>.