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 662586 - Crash when starting a second vinagre
Crash when starting a second vinagre
Status: RESOLVED FIXED
Product: vinagre
Classification: Applications
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: vinagre-maint
vinagre-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-24 09:15 UTC by Vincent Untz
Modified: 2012-07-23 23:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix up handling of commandline options (6.15 KB, patch)
2012-07-23 02:33 UTC, Matthias Clasen
accepted-commit_now Details | Review
Fix up handling of commandline options (6.15 KB, patch)
2012-07-23 23:56 UTC, Matthias Clasen
committed Details | Review

Description Vincent Untz 2011-10-24 09:15:49 UTC
Forwarding https://bugzilla.novell.com/show_bug.cgi?id=722709

It's a crash easy to reproduce:
 1) in a terminal, start "vinagre test"
 2) in a second terminal, start "vinagre test2"

Bam, crash.

The issue, I guess, is that app_command_line() uses a global variable to parse arguments, which apparently doesn't work too well once you start a second instance via GApplication.
Comment 1 Vincent Untz 2011-10-24 16:04:32 UTC
Another interesting thing: if you call "vinagre --help" while vinagre is already running, your instance of vinagre exits.

This is actually documented: see example 19 at http://developer.gnome.org/gio/stable/GApplicationCommandLine.html
Comment 2 Dominique Leuenberger 2012-07-22 15:36:10 UTC
This still happens with vinagre 3.4.2
Comment 3 Matthias Clasen 2012-07-23 02:33:56 UTC
Created attachment 219451 [details] [review]
Fix up handling of commandline options

The handling of commandlines in the primary instance was not
really working at all. Fix things up by creating a new GOptionContext
for each instance, and do the extra work to send --help output
back to the remote instance. Also return a nonzero exit status
when commandline parsing fails.
Comment 4 Dominique Leuenberger 2012-07-23 18:24:14 UTC
(In reply to comment #3)
> Created an attachment (id=219451) [details] [review]
> Fix up handling of commandline options

Added this patch to a package for testing and this indeed works without directly recognizable errors... so from a functional PoV a go.
Comment 5 David King 2012-07-23 21:23:05 UTC
Review of attachment 219451 [details] [review]:

Thanks Matthias, this looks great! Feel free to commit this yourself, or I can once I reach GUADEC.
Comment 6 Matthias Clasen 2012-07-23 23:56:57 UTC
The following fix has been pushed:
5140ed1 Fix up handling of commandline options
Comment 7 Matthias Clasen 2012-07-23 23:56:59 UTC
Created attachment 219539 [details] [review]
Fix up handling of commandline options

The handling of commandlines in the primary instance was not
really working at all. Fix things up by creating a new GOptionContext
for each instance, and do the extra work to send --help output
back to the remote instance. Also return a nonzero exit status
when commandline parsing fails.