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.

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.

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. ]

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.

Created attachment 87858 [details] [review]
Patched daemon/misc.c

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.

Just tried to add ia == NULL.

Nothing is changed. Same kind of error.

Note that the stack trace contains:

+ Trace 133397

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.

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!

Thanks lool fro updating the patch in repository.

As said by Brian, there is another error.

Here is the backtrace :

+ Trace 133428

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")

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.

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 ;-)

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.

@Sylvain: I've updated the patch in SVN with the version from Brian, could you give it a try?

Thanks!

Any update here?  I'm happy to commit this to the 2.18 branch if this fixes the problem.

@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?

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

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.

@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.

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.