Subscribing to multiple events causes several issues #4
Comments
|
Hi @runeerle42 , regarding your sms loop, have you tried something like |
|
Hi,
For the examples, none of them use Unsubscribe() or multiple different Subscribe...() at the same time. When there is just one at the same time there seems to be no errors.
I simplified the example code quite a lot. My real SMS and call loops use tickers like your example already :) But the issue is that calling Unsubscribe() for one specific event will only stop DBus events of that specific type, and listening to changes for any SMS is not possible as each is has its own DBujs event name '/org/freedesktop/ModemManager1/SMS/688'. So I call smsSend.SubscribePropertiesChanged() for every SMS, and get a channel back. This channel is not closed by the matching Unsubscribe(). Its not possible for me to close this channel either since close(smsDbus) is illegal, and must be done on the other side of the channel. Here is what I think might be wrong without debugging it directly: I don't see why this logic is failing, but perhaps it is related to events triggering on unrelated channels? Regards |
|
Hi @runeerle42 , as wrote before, I have not used these functions really - and not really expert in this area. Have you tried any upstream (go)dbus/golang version? If you have any idea how to fix this - I am open for any PR :) |
|
Hi @maltegrosse , I have tested the latest https://github.com/godbus/dbus/ @5.1.0 now and there is no change. When a modem is created with GetModems() the modem is initialized with this code. And this makes the single shared DBus signaling interface: https://github.com/godbus/dbus/blob/v5.1.0/conn.go So each instance of Subscribe() need to have a private conn object. In addition each DBus event that must be listened to need a private connection. I think this is done by replacing 'ss.conn.BusObject().Call(dbusMethodAddMatch, 0, rule)' with this function, or a similar function that makes a private connection: https://github.com/godbus/dbus/blob/v5.1.0/conn.go Hope this helps understanding what is wrong and a possible fix. Unfortunately I don't have time (or know how) to make a PR for this now. Regards |
|
@runeerle42 thank you for debugging this issue. time is limited on my side too... |
|
I have the same problem. I solved it using Here is the sample code: dbusConn, err := m.systemBusPrivate()
if err != nil {
return err
}
rule := fmt.Sprintf("type='signal', member='%s',path_namespace='%s'", modemmanager.ModemMessagingSignalAdded, fmt.Sprint(modem.GetObjectPath()))
dbusConn.BusObject().Call("org.freedesktop.DBus.AddMatch", 0, rule)
sigChan := make(chan *dbus.Signal, 10)
dbusConn.Signal(sigChan)func (m *modem) systemBusPrivate() (*dbus.Conn, error) {
dbusConn, err := dbus.SystemBusPrivate()
if err != nil {
return nil, err
}
err = dbusConn.Auth(nil)
if err != nil {
dbusConn.Close()
return nil, err
}
err = dbusConn.Hello()
if err != nil {
dbusConn.Close()
return nil, err
}
return dbusConn, nil
} |
Hi, I'm using go-modemmanager to handle outgoing and incoming SMS and voice calls.
I have two issues that I don't know why occur. Both are related to subscribing to events. The first is that subscribing to several different event types causes all channels to receive all events. The second is that unsubscribing leaks lots of memory.
Here is a code example with only the important parts:
First issue:
Second and main issue:
There are more and more hanging signals that never quit. It only happens after smsSend.Unsubscribe() is called.
After ~10 messages the number of hanging goroutines starts to grow and all hang in "deferredDeliver":
This crashes my program with OOM since a new SubscribePropertiesChanged/Unsubscribe() pair was made for each message. I believe it uses exponentially more memory because Unsubscribe() fails to trigger close() on the channel. That is, the smsDbus channel never closes as a separate test show that it still receives events even after Unsubscribe() is called.
I'm not sure if I do something wrong or if the error is somewhere else. Hope you can help me :)
Regards
Rune
The text was updated successfully, but these errors were encountered: