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 436725 - Segfaults after XMDCP chooser with IPv6
Segfaults after XMDCP chooser with IPv6
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.18.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2007-05-07 21:50 UTC by Loïc Minier
Modified: 2007-06-18 04:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patched daemon/misc.c (56.40 KB, patch)
2007-05-09 07:13 UTC, Loïc Minier
none Details | Review
proposed patch (1.27 KB, patch)
2007-05-16 04:15 UTC, Brian Cameron
none Details | Review

Description Loïc Minier 2007-05-07 21:50:51 UTC
Hi,

Sylvain Le Gall reported a crash in Debian bug http://bugs.debian.org/422483 just after choosing a host with the XMDCP chooser:


Program received signal SIGSEGV, Segmentation fault.

Thread 47135164225040 (LWP 30382)

  • #0 gdm_is_local_addr6
    at misc.c line 1177
  • #1 gdm_xdmcp_handle_query
    at xdmcp.c line 778
  • #2 gdm_xdmcp_decode_packet
    at xdmcp.c line 657
  • #3 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #4 ??
    from /usr/lib/libglib-2.0.so.0
  • #5 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #6 main
    at gdm.c line 1795

It seems to me that gdm expects id->chosen_host6 to be set when the client uses IPv6, so perhaps the wrong indirectdisplay is selected, or it's incorrect to assume chosen_host6 will be set.

Bye,
Comment 1 Sylvain Le Gall 2007-05-08 00:27:29 UTC
FYI, i don't use IPV6 (at least not in a conscious way).

There is two hosts:
* yocto XDMCP indirect + gdm (where it segfault)
* giga X -indirect yocto

ifconfig yocto:
eth0      Lien encap:Ethernet  HWaddr 00:16:3E:2B:60:AF  
          inet adr:192.168.2.2  Bcast:192.168.2.255  Masque:255.255.255.0
          adr inet6: fe80::216:3eff:fe2b:60af/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:58127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61134 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:51311357 (48.9 MiB)  TX bytes:64075134 (61.1 MiB)

lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:3575 (3.4 KiB)  TX bytes:3575 (3.4 KiB)

ifconfig giga:
eth0      Lien encap:Ethernet  HWaddr 00:E0:F4:16:7E:08  
          inet adr:192.168.0.1  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::2e0:f4ff:fe16:7e08/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1435567 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1481948 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:599027594 (571.2 MiB)  TX bytes:476273867 (454.2 MiB)
          Interruption:16 Adresse de base:0x2000 

eth1      Lien encap:Ethernet  HWaddr 00:E0:F4:16:7E:09  
          inet adr:192.168.254.1  Bcast:192.168.254.255  Masque:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:17 Adresse de base:0x4000 

eth2      Lien encap:Ethernet  HWaddr 00:E0:F4:16:7E:0A  
          inet adr:192.168.255.1  Bcast:192.168.255.255  Masque:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interruption:18 Adresse de base:0x6000 

lo        Lien encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:19008 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19008 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:13729877 (13.0 MiB)  TX bytes:13729877 (13.0 MiB)

ppp0      Lien encap:Protocole Point-à-Point  
          inet adr:86.217.27.138  P-t-P:193.253.160.3  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1350 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1326 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3 
          RX bytes:671725 (655.9 KiB)  TX bytes:168763 (164.8 KiB)

vif2.0    Lien encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          adr inet6: fe80::fcff:ffff:feff:ffff/64 Scope:Lien
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:62770 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59756 errors:0 dropped:16 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:64471666 (61.4 MiB)  TX bytes:52052466 (49.6 MiB)

xenbr0    Lien encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet adr:192.168.2.1  Bcast:0.0.0.0  Masque:255.255.255.0
          adr inet6: fe80::200:ff:fe00:0/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7509530 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5226734 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:9828094145 (9.1 GiB)  TX bytes:1640207941 (1.5 GiB)

And FYI, yocto is a Xen domU and giga a Xen dom0, on the same computer.
Comment 2 Brian Cameron 2007-05-08 03:16:02 UTC
What version of GDM are you using?  The bug report suggests you are using 2.18.1, but line 1177 of misc.c is not in the gdm_is_local_addr6 function.  Perhaps you are using code that has been patched by your distro, causing line numbers to change?  It would be helpful if you could show the line that is causing the problem.

If so, could you try using the latest version of GDM to see if that fixes your problem.  Many IPv6 fixes have gone into recent versions of GDM.
Comment 3 Loïc Minier 2007-05-08 07:26:45 UTC
Brian: yes, it's 2.18.1 and yes it's patched; one patch on misc.c drops gdm_clearenv_no_lang(), the other changes a "char buf" declaration into "unsigned char buf"; nothing more for misc.c.

[ I just triaged the huge Debian diff we had for gdm for years, and I've split it in separate patches; I'm not in the process of trying to cleanup old bugs / forwarding patches, but it's going slowly. ]
Comment 4 Brian Cameron 2007-05-09 03:18:44 UTC
Loic, thanks for the information.  But could you share with me the misc.c file after your patches (attach it to this bug report) so I can see what is going on at line 1177?  Thanks.
Comment 5 Loïc Minier 2007-05-09 07:13:02 UTC
Created attachment 87858 [details] [review]
Patched daemon/misc.c
Comment 6 Brian Cameron 2007-05-09 07:35:31 UTC
Does this bug go away if you modify the gdm_is_local_addr6 function to have the following logic at the top of the function?

if (ia == NULL)
   return FALSE;

Might not be a bad idea to add similar logic to the top of gdm_is_local_addr as well.
Comment 7 Sylvain Le Gall 2007-05-10 00:14:48 UTC
Just tried to add ia == NULL.

Nothing is changed. Same kind of error.
Comment 8 Brian Cameron 2007-05-10 04:10:53 UTC
Note that the stack trace contains:

  • #0 gdm_is_local_addr6
    at misc.c line 1177

The (ia=0x0) bit shows that we are passing a NULL into the function.  If you 
add an "if (ia == NULL) return FALSE" to the top of this function, then I can't imagine that it is crashing in the same place.

There may be more than one issue here.  Could you see if the SEGV has moved to a different location?  Perhaps we need to fix a few different places.

Comment 9 Loïc Minier 2007-05-10 06:48:16 UTC
Sylvain, I've added the patch to the Debian repository you've been using: just "svn up" the checkout and rebuild the package, it should have the new NULL test.

If it still crashes, can you copy paste an updated backtrace?  Thanks!
Comment 10 Sylvain Le Gall 2007-05-10 08:13:59 UTC
Thanks lool fro updating the patch in repository.

As said by Brian, there is another error.

Here is the backtrace :

Thread 47090035549712 (LWP 19666)

  • #0 raise
    from /lib/libc.so.6
  • #1 abort
    from /lib/libc.so.6
  • #2 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #3 g_log
    from /usr/lib/libglib-2.0.so.0
  • #4 g_assert_warning
    from /usr/lib/libglib-2.0.so.0
  • #5 gdm_xdmcp_send_forward_query6
    at xdmcp.c line 892
  • #6 gdm_xdmcp_handle_query
    at xdmcp.c line 842
  • #7 gdm_xdmcp_decode_packet
    at xdmcp.c line 657
  • #8 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #9 ??
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #11 main
    at gdm.c line 1795

FYI, the log in syslog and dameon.log is pretty useless : "Le démon GDM a été tué par un signal SIGABRT" (in english "The GDM daemon has been killed by SIGABRT signal")
Comment 11 Brian Cameron 2007-05-11 09:45:51 UTC
Note the first if-test we fixed says this:

     if ((((struct sockaddr_in *)clnt_sa)->sin_family == AF_INET &&
         gdm_is_loopback_addr (&(((struct sockaddr_in *)clnt_sa)->sin_addr)))
#ifdef ENABLE_IPV6
         || (clnt_sa->ss_family == AF_INET6 &&
         gdm_is_loopback_addr6 (&(((struct sockaddr_in6 *)clnt_sa)->sin6_addr)))
#endif

And then it falls into the else.  So it seems that both is_loopback_addr functions are returning FALSE (after our previous patch).

Then the code goes here to the else:

#ifdef ENABLE_IPV6
                     if (clnt_sa->ss_family == AF_INET6)
                        {
                          gdm_xdmcp_send_forward_query6
                                (id, (struct sockaddr_in6 *)clnt_sa,
                                &(((struct sockaddr_in6 *)clnt_sa)->sin6_addr),
                                &clnt_authlist);
                        }
                     else
#endif
                        {
                          gdm_xdmcp_send_forward_query
                                (id, (struct sockaddr_in *)clnt_sa,
                                &(((struct sockaddr_in *)clnt_sa)->sin_addr),
                                &clnt_authlist);
                        }

Perhaps we could try to make the if test something like this:

                 if (clnt_sa->ss_family == AF_INET6 &&
                    ((struct sockaddr_in6 *)clnt_sa)->sin_addr != NULL) {

So that it falls into the IPv4 logic if we aren't really dealing with an IPv6
packet here.

Also, you could try using GDM 2.19.  William Jon McCann rewrote the xdmcp 
logic and removed a lot of the ugly IPv4/IPv6 cruft so it should work more
generically now.  Does this work better?  Might not be worth investing a lot
of time fixing GDM 2.18 if we have a fix coming in 2.19.

Comment 12 Sylvain Le Gall 2007-05-14 20:22:40 UTC
The code 
if (clnt_sa->ss_family == AF_INET6 &&
                    ((struct sockaddr_in6 *)clnt_sa)->sin_addr != NULL) {

doesn't compile,

i use
if (clnt_sa->ss_family == AF_INET6 && 0) {

Because, i know it will disable a part of the code. 

In this case, i can connect without problem.

I try to compile 2.19.1. I don't perform it, because debian package patches doesn't apply well. 

Do you have enough input, or do you want me to find a way to compile 2.19.1 or do you have an other idea concerning "&& 0" test ;-)
Comment 13 Brian Cameron 2007-05-16 04:15:00 UTC
Created attachment 88258 [details] [review]
proposed patch


Sorry my suggestion in the previous comment was incorrect.  Looking more closely at the code, I wrote this patch which I verify does compile.  Can you test this patch and let me know if it fixes your problem?  If it does, then I'll move this upstream into the 2.18 branch.
Comment 14 Loïc Minier 2007-05-22 16:06:26 UTC
@Sylvain: I've updated the patch in SVN with the version from Brian, could you give it a try?

Thanks!
Comment 15 Brian Cameron 2007-06-04 04:23:44 UTC
Any update here?  I'm happy to commit this to the 2.18 branch if this fixes the problem.
Comment 16 Loïc Minier 2007-06-04 07:53:48 UTC
@Sylvain, the patch was included in the GDM package in version 2.18.2-1; do you still get the crash with 2.18.2-1?
Comment 17 Sylvain Le Gall 2007-06-04 08:40:50 UTC
Hello,

Just a quick update on why i do not give a try to the latest patch!

The configuration i use before (XEN + XDMCP with gdm in domU) seems not stable enough (problems with IRQ sharing). I decided to do further testing (no XEN) and to choose another virtualization solution (vserver). 

Since yesterday i have validated vserver and i am ready to test again this patch. I will give you an update tonight or tomorrow (Paris Time).

Regards && thanks for your patience
Comment 18 Sylvain Le Gall 2007-06-15 01:08:30 UTC
Hello,

OK, i just retested with everything up (using vserver rather than xen).

The bug seems to have disappeared.

I think that the 2.18.2-1 package closes this bug.
Comment 19 Loïc Minier 2007-06-15 07:01:27 UTC
@Brian, I included the patch from this report in the Debian package; can you perhaps commit it to the 2.18 branch?

The 2.19.x series might land soon in Debian now.
Comment 20 Brian Cameron 2007-06-18 04:32:36 UTC
Okay this patch is now in the 2.18 branch, so it will go into the next 2.18 release.  Not sure when that will be, but the code is patched for when it is done.  Marking this bug as fixed.

Thanks for your help with this.