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 326247 - gedit crashes trying to execute it multiple times
gedit crashes trying to execute it multiple times
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
git master
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
gedit QA volunteers
Depends on:
Blocks:
 
 
Reported: 2006-01-08 23:05 UTC by Marco Barisione
Modified: 2006-01-20 14:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Create a new BaconMessageConnection after accept() (4.45 KB, patch)
2006-01-20 12:43 UTC, Marco Barisione
committed Details | Review

Description Marco Barisione 2006-01-08 23:05:52 UTC
Steps to reproduce:
Trying to run gedit multiple times in few seconds (clicking on its icon or 
executing "gedit & sleep 1; gedit & sleep 0.1; gedit &") makes it crash.

Stack trace:
  • #0 IA__g_logv
  • #1 IA__g_log
    at gmessages.c line 517
  • #2 IA__g_return_if_fail_warning
    at gmessages.c line 532
  • #3 IA__g_io_channel_shutdown
    at giochannel.c line 369
  • #4 server_cb
    at bacon-message-connection.c line 127
  • #5 g_io_unix_dispatch
    at giounix.c line 162
  • #6 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #7 g_main_context_iterate
    at gmain.c line 2547
  • #8 IA__g_main_loop_run
    at gmain.c line 2751
  • #9 IA__gtk_main
    at gtkmain.c line 991
  • #10 main
    at gedit.c line 519


Other information:
The program crashes because in server_cb() conn->chan can be NULL because the 
channel has already been closed, so gedit calls g_io_channel_shutdown() on a 
NULL channel.
Comment 1 Paolo Borelli 2006-01-09 08:36:21 UTC
Bastien, this seems a bacon-message-connection bug, can you take a look?

Is it ok to just return FALSE without closing when conn->chan is NULL or conn->chan should never be null there and we need to figure out why it is NULL now?
Comment 2 Bastien Nocera 2006-01-11 13:45:40 UTC
Just return FALSE if the source is NULL (like it is in this case).
Please commit to libbacon HEAD before updating your copy.
Comment 3 Marco Barisione 2006-01-11 18:39:59 UTC
source is not NULL (gdb is wrong). The problem is is due to the same connection object used for more channels.

cd = accept (conn->serverfd, NULL, (guint *)&alen);
conn->fd = cd;
conn->is_comm = TRUE;
setup_connection (conn); // this overwrites conn->channel

The problems affects other programs, such as sound-juicer.
Comment 4 Paolo Borelli 2006-01-12 15:32:28 UTC
To makes things clearer, we are talking about a race here.

For instance  gedit & sleep 1; gedit > /dev/null & sleep 0.1; gedit > /dev/null &
triggers it for me and marco triggered the same problem in sound-juicer too.
Paolo Maggi even managed to make gedit open a  file name "ChangeLoggedit" by running gedit Changelog & gedit foo :)

Unfortunately I tried to make ./testmsg trigger the same problem but I din't manage to find the right timings, maybe because testmsg is just too fast.

However the problem seems quite clear: the server has just one "conn" and when two clients connect at the same time 1) messages can mix 2) the first client that exits destroys the channel thus triggering the assertion in the second client
Comment 5 Marco Barisione 2006-01-20 12:43:55 UTC
Created attachment 57722 [details] [review]
Create a new BaconMessageConnection after accept()

This patch creates a new BaconMessageConnection after a new connection is accepted by the server. This connections are kept in a GSList in the server connection so they are freed when the server is freed.
I have removed serverfd and server_conn_id as they are no more needed.

P.S. gedit does not close its server connection after gtk_main(). Is this wanted?
Comment 6 Bastien Nocera 2006-01-20 13:18:31 UTC
The server connection should be dropped and the socket unused when gedit exits, so not cleaning up shouldn't really be a problem.

I have managed to reproduce the problem (which is solely on the server side) by starting up a server (testmsg), and running 2 concurrent testmsg in a tight loop.

Terminal 1:
./testmsg
Terminal 2 and 3:
while [ $? -eq 0 ] ; do ./testmsg "foooooooooooooooooooooooooooooooooooooooooooooooooooooo" ; done

I've not managed to get text mixed up though like Paolo said he did.
Comment 7 Bastien Nocera 2006-01-20 13:42:25 UTC
I've modified the patch slightly (a few memleaks and not useful initial assignments), and committed it to libbacon CVS, after stress-testing it.
Thanks Marco for the patch.

2006-01-20  Bastien Nocera  <hadess@hadess.net>

        * src/bacon-message-connection.c: (setup_connection),
        (accept_new_connection), (server_cb), (try_server), (try_client),
        (bacon_message_connection_free):
        Patch from Marco Barisione <marco.bari@vene.ws> to not share connections        
        from different clients on the server side
        * src/testmsg.c: (exit_server), (print_stuff), (main):
        exit after 5 seconds of inactivity from the last message in server mode,   
        free the connection when we're exiting (Closes: #326247)

Paolo, please update your copy of this file.
Comment 8 Paolo Borelli 2006-01-20 14:11:26 UTC
Updated the copy in gedit. Closing the bug.