(In reply to comment #0)
> It looks that
> 
> /* Protected by _DBUS_LOCK (list) */
> static DBusMemPool *list_pool;
> 
> in dbus-list.c seems not to be initialized. This will be the case when in
> alloc_link() 
> 
>   if (!_DBUS_LOCK (list))
>     return FALSE;
> 
> fails.

That really shouldn't happen. _DBUS_LOCK (list) expands to _dbus_lock(_DBUS_LOCK_list) which can only fail if dbus_threads_init_default() fails, which can only fail if dbus_threads_init(NULL) fails, and that should only fail on OOM...

> #1  0x66074584 in free_link (link=0x14d314) at dbus-list.c:97

How would it allocate a non-NULL link without successfully initializing the memory pool?

Trying to get my cross-compiling environment up and running again,

(In reply to comment #1)
> (In reply to comment #0)
> > It looks that
> > 
> > /* Protected by _DBUS_LOCK (list) */
> > static DBusMemPool *list_pool;
> > 
> > in dbus-list.c seems not to be initialized. This will be the case when in
> > alloc_link() 
> > 
> >   if (!_DBUS_LOCK (list))
> >     return FALSE;
> > 
> > fails.
> 

There is another case in free_link(), when a list_pool do not contain no links (see !!!)

static void
free_link (DBusList *link)
{  
  if (!_DBUS_LOCK (list))
    _dbus_assert_not_reached ("we should have initialized global locks "
        "before we allocated a linked-list link");

  if (_dbus_mem_pool_dealloc (list_pool, link))
    {
      _dbus_mem_pool_free (list_pool);
!!!      list_pool = NULL;
    }
  
  _DBUS_UNLOCK (list);
}

calling free_link() again will result into this crash at

  if (_dbus_mem_pool_dealloc (list_pool, link))

Although this might be a dbus-glib issue there should be an assert ?

(In reply to comment #2)
> calling free_link() again will result into this crash at
> 
>   if (_dbus_mem_pool_dealloc (list_pool, link))

Ah, so it might be a double-free...

> Although this might be a dbus-glib issue there should be an assert ?

Did you compile your libdbus with asserts enabled?

(In reply to comment #3)
> (In reply to comment #2)
> > calling free_link() again will result into this crash at
> > 
> >   if (_dbus_mem_pool_dealloc (list_pool, link))
> 
> Ah, so it might be a double-free...
> 
> > Although this might be a dbus-glib issue there should be an assert ?
> 
> Did you compile your libdbus with asserts enabled?

yes 
       Building w/o assertions:  OFF             
        Building w/o checks:      OFF

On Debian unstable with Wine 1.4.1, dbus master, dbus-glib master, GLib 2.36:

/connect/tcp: .OK
/connect/nonce-tcp: 
** (test-loopback.exe:35): ERROR **: expected success but got error: org.freedesktop.DBus.Error.Failed: Failed to bind socket "127.0.0.1:44204": Address already in use

... which isn't ideal, but seems like a good start.

and on a re-run:

/connect/tcp: .OK
/connect/nonce-tcp: .OK
/message/tcp: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
....Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid
...........OK
/message/nonce-tcp: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
...............OK
/message/bad-guid: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
..............OK

Perhaps something regressed in newer Wine?

(In reply to comment #6)
> and on a re-run:

> Perhaps something regressed in newer Wine?

downgraded to wine 1.4.1 and got
/connect/tcp: .OK
/connect/nonce-tcp: .OK
/message/tcp: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
unexpected error returned from GetExtendedTcpTable: Request not supported.

....Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid

then crashed on the adress initial mentioned with pool=0

_dbus_mem_pool_dealloc (pool=0x0, element=0x14c3bc) at dbus-mempool.c:398

(In reply to comment #7)
> downgraded to wine 1.4.1 and got [...]

I see from your backtrace that it was also the /message/tcp test (or possibly /message/nonce-tcp) that failed with newer Wine, and /connect/tcp succeeded? Sorry, I didn't spot that before.

Created attachment 84730 [details] [review]
Crash fix

With the appended patch I got the following output: 

DBUS_SESSION_BUS_ADDRESS=autolaunch: wine bin/test-loopback.exe 
/connect/tcp: .OK
/connect/nonce-tcp: .OK
/message/tcp: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
unexpected error returned from GetExtendedTcpTable: Request not supported.

....Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid
...........OK
/message/nonce-tcp: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
unexpected error returned from GetExtendedTcpTable: Request not supported.

...............OK
/message/bad-guid: ..fixme:iphlpapi:GetExtendedTcpTable ulAf = 2, TableClass = 5 not supportted
unexpected error returned from GetExtendedTcpTable: Request not supported.

..............OK

Comment on attachment 84730 [details] [review]
Crash fix

Review of attachment 84730 [details] [review]:
-----------------------------------------------------------------

This is "wallpapering over the cracks": if we have allocated a non-NULL link and not yet freed it, then the list_pool ought to be non-NULL too - so we're either freeing something twice, or freeing something that wasn't even allocated from that pool. Either is a bug.

Works for me (under Debian's wine). I'm going to assume this was really the same thing as Bug #68496: linking the same test to libdbus-1.la and to libdbus-internal.la can't work.

*** This bug has been marked as a duplicate of bug 68852 ***

(In reply to comment #1)
> That really shouldn't happen. _DBUS_LOCK (list) expands to
> _dbus_lock(_DBUS_LOCK_list) which can only fail if
> dbus_threads_init_default() fails, which can only fail if
> dbus_threads_init(NULL) fails, and that should only fail on OOM...

Locking problems are consistent with having linked more than one copy of libdbus (which would have two copies of the lock - badness ensues).