Strange results when using sd_device_monitor to monitor USB device events about systemd

[sonicbhoc]

As an aside, I also noticed that I get two events for every plug and unplug. Is there a way to prevent that?

[poettering]

Now here's where it gets weird. If you plug in a device and then start watching events, then unplug the device, all fields are empty except Vendor and Vendor ID, which have garbage data (//////� and �����, respectively).

On unplug, Vendor ID is always garbage (�����).

smells a lot like a memory corruption in your code. Maybe valgrind the thing?

[poettering]

I don't grok your code. you never allocate an event loop, not sure how anything would work there. Hence sd_device_monitor_get_event() should always return NULL?

[poettering]

As an aside, I also noticed that I get two events for every plug and unplug. Is there a way to prevent that?

my edcuated guess, it's the "add" and "bind" events. i.e. use sd_device_get_action() to see which event it is

[sonicbhoc]

As an aside, I also noticed that I get two events for every plug and unplug. Is there a way to prevent that?

my edcuated guess, it's the "add" and "bind" events. i.e. use sd_device_get_action() to see which event it is

Thank you, I'll look into this.

I don't grok your code. you never allocate an event loop, not sure how anything would work there. Hence sd_device_monitor_get_event() should always return NULL?

No offense, but the documentation for some these libraries is just short of nonexistent.

Doesn't sd_device_monitor_new and sd_device_monitor_start set up an event loop? If not, how are they supposed to work in relation to sd_device_monitor_get_event? And if not, how does this code work at all?

[poettering]

As an aside, I also noticed that I get two events for every plug and unplug. Is there a way to prevent that?

my edcuated guess, it's the "add" and "bind" events. i.e. use sd_device_get_action() to see which event it is

Thank you, I'll look into this.

I don't grok your code. you never allocate an event loop, not sure how anything would work there. Hence sd_device_monitor_get_event() should always return NULL?

No offense, but the documentation for some these libraries is just short of nonexistent.

None taken, yeah, some are better documented than others. sd-device docs could use some love.

Doesn't sd_device_monitor_new and sd_device_monitor_start set up an event loop?

They do not.

If not, how are they supposed to work in relation to sd_device_monitor_get_event?

You attach them to an event loop via sd_device_monitor_attach_event(). That event loop you can in turn integrate into another event loop of your choice, see sd_event_get_fd()

[sonicbhoc]

Oh... I'm surprised this code doesn't explode then.

[sonicbhoc]

I just need a simple event that runs in its own thread and spits out structures. I'll start by looking at the options available to me in sd_event (which seems to be somewhat better documented) and see what happens. Thank you for taking the time to point me in the right direction.

[sonicbhoc]

Doesn't sd_device_monitor_new and sd_device_monitor_start set up an event loop?

They do not.

If not, how are they supposed to work in relation to sd_device_monitor_get_event?

You attach them to an event loop via sd_device_monitor_attach_event(). That event loop you can in turn integrate into another event loop of your choice, see sd_event_get_fd()

So, if I'm using sd_device_monitor_attach_event, should I not use sd_device_monitor_get_event? What is the purpose of that function?

[sonicbhoc]

After starting the event loop myself and attaching the monitor to the event loop using sd_device_monitor_attach_event, the results are the same. I'll try to use valgrind next to see what's happening.

[poettering]

I just need a simple event that runs in its own thread

threads you say? i do hope you are not passing around the memory that sd-device gives you pointers to to other threads. sd-device/sd-event/… is not thread-safe (it's threads aware though, i.e. as long as you use an object only from a single thread you are fine), and you must copy out everything you want to pass to other threads.

[sonicbhoc]

Now here's where it gets weird. If you plug in a device and then start watching events, then unplug the device, all fields are empty except Vendor and Vendor ID, which have garbage data (//////� and �����, respectively).
On unplug, Vendor ID is always garbage (�����).

smells a lot like a memory corruption in your code. Maybe valgrind the thing?

Yep, turns out I didn't initialize the strings in the structure I'm copying the data to. The structures are now just consistently empty when the device is unplugged. It seems like this is normal though, right?

I just need a simple event that runs in its own thread

threads you say? i do hope you are not passing around the memory that sd-device gives you pointers to to other threads. sd-device/sd-event/… is not thread-safe (it's threads aware though, i.e. as long as you use an object only from a single thread you are fine), and you must copy out everything you want to pass to other threads.

I read that in the documentation. I haven't added threading yet; I'm just trying to get it running the way I expect it to first (and it looks like I just did; no issues reported by valgrind).

[sonicbhoc]

I got the application running now. Thank you so much for your help. Unfortunately, I now have to restructure some more of the program I was writing to accommodate for the fact that unplugging a device returns nothing from the sd_device_get_property_value functions, but that shouldn't be anywhere near as painful.

[poettering]

Yep, turns out I didn't initialize the strings in the structure I'm copying the data to. The structures are now just consistently empty when the device is unplugged. It seems like this is normal though, right?

Yes, that's correct. When a device goes away we cannot talk to it anymore. Hence most props are gone by then.

[sonicbhoc]

I should have realized that. Thank you for all your help, Mr. Poettering! You are a gentleman, and a scholar.