Ok, I can finally reproduce it (without /etc/hostconfig settings or / etc/hosts settings) via: ~ $ xauth add :0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0 Bus error --- This works: ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0 --- And the sequence causing the bus error seems to work fine on linux. Thanks, Jeremy On Jan 10, 2008, at 13:56, John Koren wrote:
Just 'jnlt'. In my /etc/hosts I have '127.0.0.1 localhost jnlt'.
-John
On Jan 10, 2008 1:42 PM, Jeremy Huddleston < jeremyhu@berkeley.edu> wrote: BTW, what was the entry in /etc/hostconfig? Was it a fully qualified domain name? Or just 'jnlt'?
Ok, I've put together a summary of most of my debugging here: http://trac.macosforge.org/projects/xquartz/ticket/44 I've narrowed it down to one oddity, and I'm getting to a point where I want to take a break for a while... so I'll probably try working on this tomorrow unless someone else finishes up where I started... and hopefully someone with more experience with xauth will chime in (hence the CC to xorg@). Basically, OSX's /etc/hosts file has three localhost entries: 127.0.0.1 localhost ::1 localhost fe80::1%lo0 localhost Commenting out that last one causes our problem to go away, but that's not good enough. It should work! So here's the main thing I noticed: Doing xauth add localhost:0 before :0 causes two ipv6 xauth entries to be created for localhost and one ipv4 entry (presumably this is somehow one for each line in /etc/hosts as commenting out the last localhost line in /etc/hosts causes one less ipv6 entry). If we did the add :0 before localhost:0, then the localhost:0 addition would add just one ipv4 entry and one ipv6 entry (even with the last /etc/hosts line present). Then doing the 'xauth remove localhost:0', I noticed that we called remove_entry() attempting to remove the ipv6 entry twice (even though there was only one in the list when doing the :0 add before the localhost:0 add). If we did the localhost:0 add first, there would be a second ipv6 entry to remove, so it wouldn't crash. So... a few questions for someone on xorg@l.f.o who can hopefully help me out here: 1) Why is the second ipv6 entry being added at all? It seems like it should only be added once. So why is it behaving that way in one ordering of adds and not the other? 2) Why is remove_entry() being called a second time with the ipv6 auth removal even when there is only one matching auth in the list. Looking at iterdpy(), I don't see why that should be happening as it iterates over the same list being removed from. On Jan 10, 2008, at 14:22, Jeremy Huddleston wrote:
Ok, I can finally reproduce it (without /etc/hostconfig settings or / etc/hosts settings) via:
~ $ xauth add :0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0 Bus error
---
This works: ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0
---
And the sequence causing the bus error seems to work fine on linux.
Thanks, Jeremy
On Jan 10, 2008, at 13:56, John Koren wrote:
Just 'jnlt'. In my /etc/hosts I have '127.0.0.1 localhost jnlt'.
-John
On Jan 10, 2008 1:42 PM, Jeremy Huddleston < jeremyhu@berkeley.edu> wrote: BTW, what was the entry in /etc/hostconfig? Was it a fully qualified domain name? Or just 'jnlt'?
Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
So actually, I traced it back to duplicate entries appearing as a result of get_address_info()... and that seems to be coming from OSX's getaddrinfo() returning the duplicate entry: Is this a bug in getaddrinfo()? Should it not be returning duplicates? I don't see in the documentation anywhere that it guarantees uniqueness... so I'm going to try whipping together a patch to get_address_info() which prevents the duplicates from being passed on to the caller of get_address_info()... hopefully that will solve our problem. (gdb) n 296 if (getaddrinfo(host,NULL,&hints,&firstai) !=0) return NULL; (gdb) n 297 for (ai = firstai; ai != NULL; ai = ai->ai_next) { (gdb) print *firstai $1 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x3003e0, ai_next = 0x300400 } (gdb) print *firstai->ai_next $2 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x300420, ai_next = 0x300440 } (gdb) print *firstai->ai_next->ai_next $3 = { ai_flags = 0, ai_family = 2, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 16, ai_canonname = 0x0, ai_addr = 0x3004a0, ai_next = 0x0 } (gdb) print *firstai->ai_addr $4 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) print *firstai->ai_next->ai_addr $5 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) On Jan 10, 2008, at 20:25, Jeremy Huddleston wrote:
Ok,
I've put together a summary of most of my debugging here: http://trac.macosforge.org/projects/xquartz/ticket/44
I've narrowed it down to one oddity, and I'm getting to a point where I want to take a break for a while... so I'll probably try working on this tomorrow unless someone else finishes up where I started... and hopefully someone with more experience with xauth will chime in (hence the CC to xorg@).
Basically, OSX's /etc/hosts file has three localhost entries:
127.0.0.1 localhost ::1 localhost fe80::1%lo0 localhost
Commenting out that last one causes our problem to go away, but that's not good enough. It should work! So here's the main thing I noticed:
Doing xauth add localhost:0 before :0 causes two ipv6 xauth entries to be created for localhost and one ipv4 entry (presumably this is somehow one for each line in /etc/hosts as commenting out the last localhost line in /etc/hosts causes one less ipv6 entry). If we did the add :0 before localhost:0, then the localhost:0 addition would add just one ipv4 entry and one ipv6 entry (even with the last /etc/ hosts line present).
Then doing the 'xauth remove localhost:0', I noticed that we called remove_entry() attempting to remove the ipv6 entry twice (even though there was only one in the list when doing the :0 add before the localhost:0 add). If we did the localhost:0 add first, there would be a second ipv6 entry to remove, so it wouldn't crash.
So... a few questions for someone on xorg@l.f.o who can hopefully help me out here:
1) Why is the second ipv6 entry being added at all? It seems like it should only be added once. So why is it behaving that way in one ordering of adds and not the other?
2) Why is remove_entry() being called a second time with the ipv6 auth removal even when there is only one matching auth in the list. Looking at iterdpy(), I don't see why that should be happening as it iterates over the same list being removed from.
On Jan 10, 2008, at 14:22, Jeremy Huddleston wrote:
Ok, I can finally reproduce it (without /etc/hostconfig settings or /etc/hosts settings) via:
~ $ xauth add :0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0 Bus error
---
This works: ~ $ xauth add localhost:0 MIT-MAGIC-COOKIE-1 ce234f956a2ddef8eb2d94fb9bd6af81 ~ $ xauth remove localhost:0
---
And the sequence causing the bus error seems to work fine on linux.
Thanks, Jeremy
On Jan 10, 2008, at 13:56, John Koren wrote:
Just 'jnlt'. In my /etc/hosts I have '127.0.0.1 localhost jnlt'.
-John
On Jan 10, 2008 1:42 PM, Jeremy Huddleston < jeremyhu@berkeley.edu> wrote: BTW, what was the entry in /etc/hostconfig? Was it a fully qualified domain name? Or just 'jnlt'?
Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Jan 10, 2008, at 8:55 PM, Jeremy Huddleston wrote:
So actually, I traced it back to duplicate entries appearing as a result of get_address_info()... and that seems to be coming from OSX's getaddrinfo() returning the duplicate entry:
Is this a bug in getaddrinfo()? Should it not be returning duplicates? I don't see in the documentation anywhere that it guarantees uniqueness... so I'm going to try whipping together a patch to get_address_info() which prevents the duplicates from being passed on to the caller of get_address_info()... hopefully that will solve our problem.
(gdb) n 296 if (getaddrinfo(host,NULL,&hints,&firstai) !=0) return NULL; (gdb) n 297 for (ai = firstai; ai != NULL; ai = ai->ai_next) { (gdb) print *firstai $1 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x3003e0, ai_next = 0x300400 } (gdb) print *firstai->ai_next $2 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x300420, ai_next = 0x300440 }
These are both AF_INET6, IPPROTO_TCP, SOCK_STREAM.
(gdb) print *firstai->ai_addr $4 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) print *firstai->ai_next->ai_addr $5 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> }
What are the full contents of both of these? They're struct sockaddr_in6, 28 bytes long. They may not be duplicates because this only shows the first 16 bytes. My guess is that you're seeing IPv6 loopback on two different interfaces (i.e. ::1%en0 for ethernet and ::1%en1 for wifi), or perhaps an unscoped ::1 and a interface-specific ::1. In these cases, sin6_addr will be all zeros with 0x01 at the end, and sin6_scope_id (the last 4 of the 28 bytes) will differ. -- Greg Parker gparker@apple.com Runtime Wrangler
Hi Greg, Here's a stripped down app which reveals the problem. Compile and run './getaddrtest localhost' to see (up to endianness for the ipv4 addr): entry 0: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 1: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 2: Family: AF_INET Address: 127.1.1.1 Note that the scope_id is the same... And I think that about covers all the items in sockaddr_in6 that we could match: struct in6_addr { union { __uint8_t __u6_addr8[16]; __uint16_t __u6_addr16[8]; __uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ }; #define s6_addr __u6_addr.__u6_addr8 struct sockaddr_in6 { __uint8_t sin6_len; /* length of this struct(sa_family_t)*/ sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */ in_port_t sin6_port; /* Transport layer port # (in_port_t)*/ __uint32_t sin6_flowinfo; /* IP6 flow information */ struct in6_addr sin6_addr; /* IP6 address */ __uint32_t sin6_scope_id; /* scope zone index */ }; On Jan 10, 2008, at 21:37, Greg Parker wrote:
On Jan 10, 2008, at 8:55 PM, Jeremy Huddleston wrote:
So actually, I traced it back to duplicate entries appearing as a result of get_address_info()... and that seems to be coming from OSX's getaddrinfo() returning the duplicate entry:
Is this a bug in getaddrinfo()? Should it not be returning duplicates? I don't see in the documentation anywhere that it guarantees uniqueness... so I'm going to try whipping together a patch to get_address_info() which prevents the duplicates from being passed on to the caller of get_address_info()... hopefully that will solve our problem.
(gdb) n 296 if (getaddrinfo(host,NULL,&hints,&firstai) !=0) return NULL; (gdb) n 297 for (ai = firstai; ai != NULL; ai = ai->ai_next) { (gdb) print *firstai $1 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x3003e0, ai_next = 0x300400 } (gdb) print *firstai->ai_next $2 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x300420, ai_next = 0x300440 }
These are both AF_INET6, IPPROTO_TCP, SOCK_STREAM.
(gdb) print *firstai->ai_addr $4 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) print *firstai->ai_next->ai_addr $5 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> }
What are the full contents of both of these? They're struct sockaddr_in6, 28 bytes long. They may not be duplicates because this only shows the first 16 bytes.
My guess is that you're seeing IPv6 loopback on two different interfaces (i.e. ::1%en0 for ethernet and ::1%en1 for wifi), or perhaps an unscoped ::1 and a interface-specific ::1. In these cases, sin6_addr will be all zeros with 0x01 at the end, and sin6_scope_id (the last 4 of the 28 bytes) will differ.
-- Greg Parker gparker@apple.com Runtime Wrangler
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ack, sorry... I forgot to update the version of the code in my email to match what was saved on disk before I sent it. Here you go... On Jan 10, 2008, at 22:35, Jeremy Huddleston wrote:
Hi Greg,
Here's a stripped down app which reveals the problem. Compile and run './getaddrtest localhost' to see (up to endianness for the ipv4 addr):
entry 0: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 1: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 2: Family: AF_INET Address: 127.1.1.1
Note that the scope_id is the same... And I think that about covers all the items in sockaddr_in6 that we could match:
struct in6_addr { union { __uint8_t __u6_addr8[16]; __uint16_t __u6_addr16[8]; __uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ };
#define s6_addr __u6_addr.__u6_addr8
struct sockaddr_in6 { __uint8_t sin6_len; /* length of this struct(sa_family_t)*/ sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */ in_port_t sin6_port; /* Transport layer port # (in_port_t)*/ __uint32_t sin6_flowinfo; /* IP6 flow information */ struct in6_addr sin6_addr; /* IP6 address */ __uint32_t sin6_scope_id; /* scope zone index */ };
<getaddrtest.c>
On Jan 10, 2008, at 21:37, Greg Parker wrote:
On Jan 10, 2008, at 8:55 PM, Jeremy Huddleston wrote:
So actually, I traced it back to duplicate entries appearing as a result of get_address_info()... and that seems to be coming from OSX's getaddrinfo() returning the duplicate entry:
Is this a bug in getaddrinfo()? Should it not be returning duplicates? I don't see in the documentation anywhere that it guarantees uniqueness... so I'm going to try whipping together a patch to get_address_info() which prevents the duplicates from being passed on to the caller of get_address_info()... hopefully that will solve our problem.
(gdb) n 296 if (getaddrinfo(host,NULL,&hints,&firstai) !=0) return NULL; (gdb) n 297 for (ai = firstai; ai != NULL; ai = ai->ai_next) { (gdb) print *firstai $1 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x3003e0, ai_next = 0x300400 } (gdb) print *firstai->ai_next $2 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x300420, ai_next = 0x300440 }
These are both AF_INET6, IPPROTO_TCP, SOCK_STREAM.
(gdb) print *firstai->ai_addr $4 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) print *firstai->ai_next->ai_addr $5 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> }
What are the full contents of both of these? They're struct sockaddr_in6, 28 bytes long. They may not be duplicates because this only shows the first 16 bytes.
My guess is that you're seeing IPv6 loopback on two different interfaces (i.e. ::1%en0 for ethernet and ::1%en1 for wifi), or perhaps an unscoped ::1 and a interface-specific ::1. In these cases, sin6_addr will be all zeros with 0x01 at the end, and sin6_scope_id (the last 4 of the 28 bytes) will differ.
-- Greg Parker gparker@apple.com Runtime Wrangler
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Jan 10, 2008, at 10:35 PM, Jeremy Huddleston wrote:
Here's a stripped down app which reveals the problem. Compile and run './getaddrtest localhost' to see (up to endianness for the ipv4 addr):
entry 0: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 1: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 2: Family: AF_INET Address: 127.1.1.1
Note that the scope_id is the same... And I think that about covers all the items in sockaddr_in6 that we could match:
Yep, I see the same thing. Interestingly, `getaddrtest localhost.` (note dot) only reports one copy of ::1. (The trailing dot means "don't search the default DNS suffixes". A lookup for "hamster" would find "hamster.apple.com" on my machine here, but "hamster." would not.) So there's definitely something fishy with getaddrinfo() here. File a bug report, and sanity-check the list in xauth. -- Greg Parker gparker@apple.com Runtime Wrangler
participants (3)
-
Greg Parker
-
Jeremy Huddleston
-
Jeremy Huddleston