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 667245 - Regression: segfault on soup_connection_get_state
Regression: segfault on soup_connection_get_state
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
2.37.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
: 667114 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-01-04 09:33 UTC by Claudio Saavedra
Modified: 2012-03-01 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Claudio Saavedra 2012-01-04 09:33:53 UTC 
The regression seems to be after this commit:

commit d4ec04f41d4de39a7b9091f0d0572ce11565a4ab
Author: Dan Winship <danw@gnome.org>
Date:   Wed Dec 7 17:03:19 2011 -0500

    SoupConnection: belatedly fix up unix-only code

    The last-minute-check-if-the-socket-has-been-closed-by-the-server code
    was written long ago to use soup_socket_get_fd() and g_poll(), and so
    was unix-only, but now that SoupSocket is GSocket-based, we can use
    g_socket_condition_check() instead.

This stacktrace is with a patched glib, not to crash on a g_socket_*() calls with NULL, but you shouldn't be passing NULL to glib anyway:

+ Trace 229385

  • #0 g_logv
    at gmessages.c line 758
  • #1 g_log
    at gmessages.c line 792
  • #2 g_return_if_fail_warning
  • #3 g_socket_condition_check
    at gsocket.c line 2697
  • #4 soup_connection_get_state
    at soup-connection.c line 889
  • #5 soup_session_cleanup_connections
    at soup-session.c line 1742
  • #6 run_queue
    at soup-session-async.c line 453
  • #7 idle_run_queue
    at soup-session-async.c line 487
  • #8 g_idle_dispatch
    at gmain.c line 4632
  • #9 g_main_dispatch
    at gmain.c line 2513
  • #10 g_main_context_dispatch
    at gmain.c line 3050
  • #11 g_main_context_iterate
    at gmain.c line 3121
  • #12 g_main_context_iteration
    at gmain.c line 3182
  • #13 g_application_run
    at gapplication.c line 1599
  • #14 main
    at ephy-main.c line 472 






Comment 1


Claudio Saavedra





          2012-01-04 09:34:56 UTC
        



By the way, this is very easy to reproduce with latest epiphany and youtube with HTML5 enabled (youtube.com/html5).






Comment 2


Dan Winship





          2012-01-04 13:38:45 UTC
        



(In reply to comment #1)
> By the way, this is very easy to reproduce with latest epiphany and youtube
> with HTML5 enabled (youtube.com/html5).

worksforme...

I assume you have the latest glib and glib-networking too?






Comment 3


Dan Winship





          2012-01-04 15:01:13 UTC
        



(In reply to comment #0)
> The regression seems to be after this commit:
> 
> commit d4ec04f41d4de39a7b9091f0d0572ce11565a4ab

If it crashes after that commit, it would have to have been already hitting a g_return_val_if_fail() before that commit. If you can bisect to a commit where the return-if-fail first appears, that would be useful... Also, if any other warnings appear before this one.

Hm. Are you using a proxy? (Just trying to think of things that would make it work differently for you than for me.)






Comment 4


Dan Winship





          2012-01-04 15:35:51 UTC
        



*** Bug 667114 has been marked as a duplicate of this bug. ***






Comment 5


Claudio Saavedra





          2012-01-04 16:07:34 UTC
        



I think I saw similar warnings after the previous commit, ff0797686c3a893ef2a5b6950356336a0712da27. Before that everything seems ok. I'm not using a proxy.






Comment 6


Frederic Peters





          2012-01-05 11:59:44 UTC
        



I am also pretty sure I had this libsoup commit already when I hit the segfault from bug 667114, and I'm not using a proxy.






Comment 7


Xan Lopez





          2012-01-05 18:34:48 UTC
        



FWIW I could not make the browser crash until I hit commit f4478b4fba, which is the next one to the one Claudio mentions. I browsed for ~30 minutes with ff0797686c3 and d4ec04f41d4 without crash, but f4478b4fba crashed reasonably quickly. Of course this is by no means scientific, but perhaps the breakage coming from there makes more sense for Dan.






Comment 8


Jean Louis [reporter][developer]





          2012-02-17 16:12:18 UTC
        



Hi,

I confirm this bug with midori browser on ARM board with thiese libsoup packages :


libsoup-2.4 - 2.37.2-r1
libsoup-2.4-1 - 2.33.6-r0.9
libsoup-2.4-dbg - 2.37.2-r1
libsoup-gnome-2.4-1 - 2.33.6-r0.9


The backtrace is :

Program received signal SIGSEGV, Segmentation fault.
g_socket_get_fd (socket=0x0) at gsocket.c:1238
1238      return socket->priv->fd;
(gdb) bt




+
Trace
    229688






    

  • 
#0
g_socket_get_fd

    
                at gsocket.c
                  line
                  1238

    

    • 

  • 
#1
soup_connection_get_state

    
                at soup-connection.c
                  line
                  803

    

    • 

  • 
#2
soup_session_cleanup_connections

    
                at soup-session.c
                  line
                  1657

    

    • 

  • 
#3
run_queue

    
                at soup-session-async.c
                  line
                  455

    

    • 

  • 
#4
idle_run_queue

    
                at soup-session-async.c
                  line
                  489

    

    • 

  • 
#5
g_idle_dispatch

    
                at gmain.c
                  line
                  4801

    

    • 

  • 
#6
g_main_dispatch

    
                at gmain.c
                  line
                  2441

    

    • 

  • 
#7
g_main_context_dispatch

    
                at gmain.c
                  line
                  3011

    

    • 

  • 
#8
g_main_context_iterate

    
                at gmain.c
                  line
                  3089

    

    • 

  • 
#9
g_main_loop_run

    
                at gmain.c
                  line
                  3297

    

    • 

  • 
#10
IA__gtk_main

    
                at gtkmain.c
                  line
                  1256

    

    • 

  • 
#11
main

    • 








Hope that helps !

Bye.






Comment 9


Jean Louis [reporter][developer]





          2012-02-23 10:06:52 UTC
        



Hi,

I can reproduce it when I cancel the loading of one (big) internet page.

For example : http://www.permadi.com/tutorial/jsEventBubbling/index.html

I repeat refresh and cancel many times and the bug occurs.

Sincerely, JL.






Comment 10


Dan Winship





          2012-02-25 18:21:32 UTC
        



that doesn't crash for me either.

are people who see the crash on 32-bit architectures maybe?






Comment 11


Thierry Reding





          2012-02-25 20:16:50 UTC
        



(In reply to comment #10)
> that doesn't crash for me either.
> 
> are people who see the crash on 32-bit architectures maybe?

Yes, I've seen this bug on both 32-bit x86 (i686) and 32-bit ARM.

Thierry






Comment 12


Dan Winship





          2012-03-01 16:38:19 UTC
        



Fixed in git. (the 32-bit had nothing to do with it. I have no idea
why I couldn't reproduce this before, but I could today...)