After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654442 - Problems with two GUPnPContexts on the same port
Problems with two GUPnPContexts on the same port
Status: RESOLVED FIXED
Product: GUPnP
Classification: Other
Component: gupnp
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jens Georg
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-07-12 09:08 UTC by Jens Georg
Modified: 2011-08-04 20:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix issue, version 1 (5.23 KB, patch)
2011-07-12 10:29 UTC, Jens Georg
none Details | Review
Fail context creation if port for HTTP is bound (2.55 KB, patch)
2011-07-20 09:55 UTC, Jens Georg
none Details | Review
Fail context creation if port for HTTP is bound (2.55 KB, patch)
2011-07-20 10:53 UTC, Jens Georg
accepted-commit_now Details | Review

Description Jens Georg 2011-07-12 09:08:35 UTC
If you create two GUPnPContexts on the same interface and port, you don't get an error right away. Instead, when lazy-creating the SoupServer instance, it will show loads of warnings and criticals and living with a defunct SoupServer.
Comment 1 Ross Burton 2011-07-12 09:12:20 UTC
So I guess we should make GUPnPContext a GInitable and create the server there.
Comment 2 Jens Georg 2011-07-12 09:27:47 UTC
It's already a GInitable, so the hard part is done. I plan to provide a patch later, the bug is more a note to self while digging for another problem.

One issue I see is that I don't see any way to figure out if the SoupServer had a problem or not, see:

gjs> const Soup = imports.gi.Soup;
gjs> new Soup.Server ({'port' : 1234});
[object instance proxy GIName:Soup.Server jsobj@0x7fe7cb011410 native@0x188f070]
gjs> new Soup.Server ({'port' : 1234})
(gjs:17064): GLib-GObject-CRITICAL **: g_object_is_floating: assertion `G_IS_OBJECT (object)' failed

(gjs:17064): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

(gjs:17064): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(gjs:17064): GLib-GObject-CRITICAL **: g_object_add_toggle_ref: assertion `G_IS_OBJECT (object)' failed

(gjs:17064): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
[object prototype of GIName:Soup.Server jsobj@0x7fe7cb0114e0]
Comment 3 Jens Georg 2011-07-12 09:40:34 UTC
(In reply to comment #2)
> It's already a GInitable, so the hard part is done. I plan to provide a patch
> later, the bug is more a note to self while digging for another problem.
> 
> One issue I see is that I don't see any way to figure out if the SoupServer had
> a problem or not, see:

Hm, no. That's a gjs issue. soup_server_new returns NULL then.
Comment 4 Jens Georg 2011-07-12 10:29:15 UTC
Created attachment 191800 [details] [review]
Fix issue, version 1

Move the server to g_initable_init(). I'm not sure if this is completely correct, since this creates a SoupServer for every context and I don't know if there can be a context without a server.
Comment 5 Jens Georg 2011-07-20 09:55:18 UTC
Created attachment 192291 [details] [review]
Fail context creation if port for HTTP is bound
Comment 6 Jens Georg 2011-07-20 09:56:44 UTC
New version. Only create a HTTP server in initable_init() if the port is non-zero. This is under the assumption that if you pass a port, you will need the HTTP server anyway. And if port is 0, server creation will most likely succeed anyway.
Comment 7 Jens Georg 2011-07-20 10:53:09 UTC
Created attachment 192293 [details] [review]
Fail context creation if port for HTTP is bound
Comment 8 Zeeshan Ali 2011-08-04 20:22:43 UTC
Review of attachment 192293 [details] [review]:

Looks good!
Comment 9 Jens Georg 2011-08-04 20:47:56 UTC
commited.