Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#16774 closed defect (fixed)

dbus-1.2.3_0 has memory allocation failures on 10.4.11

Reported by: aetherknight@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.6.0
Keywords: Cc: pgijnxn02@…, dbevans (David B. Evans)
Port: dbus

Description

After updating from dbus-1.2.1_0 to dbus-1.2.3_0 on Mac OS X 10.4.11, dbus no longer seems able to run. This problem appears to occur on both Intel and PowerPC Macs.

With version 1.2.1_0, running dbus-launch yielded along the lines of

DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-E76qJe6mCa,guid=27b56f31090159b15b9b087148ea6f54
DBUS_SESSION_BUS_PID=22167

and the dbus-daemon process can be seen with the ps command.

After updating to 1.2.3_0, running dbus-launch prints

Failed to start message bus: Memory allocation failure in message bus
EOF in dbus-launch reading address from bus daemon

Building dbus @1.2.3_0 in a cleanly installed MacPorts environment does not fix this.

This bug causes applications, such as gnucash, to be unable to find their gconf configurations.

Change History (7)

comment:1 Changed 12 years ago by mf2k (Frank Schima)

Port: dbus added

I updated dbus to 1.2.4 in r40564. It runs fine for me. Does this fix the problem for you?

comment:2 Changed 12 years ago by pgijnxn02@…

Cc: pgijnxn02@… added

Cc Me!

comment:3 Changed 12 years ago by dbevans (David B. Evans)

Cc: db.evans@… added

Cc Me!

comment:4 in reply to:  1 Changed 12 years ago by dbevans (David B. Evans)

Replying to macsforever2000@…:

I updated dbus to 1.2.4 in r40564. It runs fine for me. Does this fix the problem for you?

After updating to dbus 1.2.4 on 10.4.11 ppc, running dbus-launch yields

DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-T5DlNFQjEQ,guid=2b780c3108f1012ab217b32d48eb9f4c
DBUS_SESSION_BUS_PID=14394

and ps ax gives

14394  ??  Ss     0:00.00 /opt/local/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session

but applications that use GConf continue to be unable to contact gconfd. In fact, it appears that gconfd is failing to launch in response to requests from applications. Normal behavior is to launch gconfd automatically for the first application that makes a request for a given user if no instance is already running and then quit after a timeout period if no additional requests are received. This doesn't appear to be happening.

comment:5 Changed 12 years ago by pgijnxn02@…

comment:6 Changed 12 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

comment:7 Changed 11 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.