Re: libsoup websocket server memory problems

[Claudio Saavedra <csaavedra gnome org>]

On Wed, 2020-01-15 at 14:12 +0100, Benjamin Reikowski wrote:
> Hello libsoup mailing list members,
>
> I'm using the libsoup websocket server and recently updated my
> libsoup from
> 2.64.2 to 2.68.3 due to a bug that has been fixed with
> https://github.com/GNOME/libsoup/commit/35f1bac5ff9ec694e64b65e51f0e7a3226aa3aaf
[...]

> This assertion is new and did not happen before the commit I
> mentioned at the beginning. I do NOT run into this g_assert if I'm
> either not using g_object_unref(ws) in function
> websocket_client_closed_cb or delay it by 1s. But I HAVE to use
> g_object_ref(ws) in function websocket_client_connect_cb otherwise
> the SoupWebsocketConnection *ws would not survive. After I discovered
> that, I took a look into your regression code (namely
> tests/websocket-tests.c) and found you doing the same:
> g_object_ref(ws) on every client connect and no g_object_unref(ws) on
> "closed".

The test program does drop the reference to the websocket connection at
some point durign teardown. See the
teardown_direct_connection_method().

You need to keep a reference to the connection, since you're
responsible for it. I think it's reasonably to drop it in the "closed"
handler, but there might be a bug there.

> At last, I used valgrind on my example code and found out that it's
> pretty leaky w/o g_object_unref(ws).
>
> So my question: did I do something wrong in my example code or is
> this possibly a bug?

It's possibly a bug. It would be helpful if you could 

1. get a stacktrace at the assertion failure.

2. Enable debug output, I think G_MESSAGES_DEBUG is useful for that.

I think you could report it in gitlab if you have that info. 

The commit you referenced above changed how the input sources work. It
is possible that we overlooked something (like that it's possible that
during finalize there is no input source at all).


Claudio