Ivan Malison @IvanMalison 14:58
@garetxe Ahh, so it looks like this is a double free on the gthread object: If i extend the log back a bit
Paste created: https://gist.github.com/15835bbde2435d20eb800b263859302c

you can see that the thread is freed twice
Iñaki @garetxe 14:59
Yep, indeed
Ivan Malison @IvanMalison 15:00
@garetxe So I don't think that this is glib internally deciding to do something, because both of the frees are logged from the haskell-gi logger
is that correct?
Iñaki @garetxe 15:00
Yes, that sounds right
On the other hand the garbage collector will only try to free it once, unless two Haskell objects point to the same block of memory. Which can happen, unfortunately...
Ivan Malison @IvanMalison 15:04
I'm actually kind of confused about what might even be creating the haskell GThread objects in the first place
Iñaki @garetxe 15:07
It could be a function returning that (it will be wrapped, even if you don't use it)
Or alternatively a callback being invoked with a GThread argument, although newer versions of haskell-gi will not try to free these.
Ivan Malison @IvanMalison 15:14
hmm okay, well I have narrowed context significatnly. I know that something in https://github.com/travitch/taffybar/blob/e00c30ed843f2fa02d1095ce52352fc11a40a4a0/src/System/Taffybar/Widget/MPRIS2.hs#L2 is causing the allocation of GThread objects
@garetxe its happening here: https://github.com/haskell-gi/gi-gtk-hs/blob/0ddb4ee2b1bce874a8ddbe609af3ee45d2563f71/src/Data/GI/Gtk/Threading.hs#L125
thats where the threads are allocated
Iñaki @garetxe 15:23
Ah, I see. compareThreads itself does no allocation, but probably the issue is in the related threadSelf call.
Ivan Malison @IvanMalison 15:23
yes, I think the wrapBoxed there is technically racy
or not racy, but like: What stops multiple calls of this?
Iñaki @garetxe 15:28
If you read the docs for the function, it states that the ref of the returned GThread is not increased. But if you look to the generated bindings, for some reason wrapBoxed is used, which will unref once the Haskell object is garbage collected.
So if the docs are right, this would explain the crash you see.
Ivan Malison @IvanMalison 15:28
right, we should use newObject, right?
Iñaki @garetxe 15:29
copyBoxed, rather, but yes.
Ivan Malison @IvanMalison 15:29
will that work for the comparison though?
I imagine that this would no longer work: https://github.com/haskell-gi/gi-gtk-hs/blob/0ddb4ee2b1bce874a8ddbe609af3ee45d2563f71/src/Data/GI/Gtk/Threading.hs#L127
but maybe im mistaken
Iñaki @garetxe 15:30
copyBoxed will probably just increase the ref (but I need to check).
So the pointer itself will not change.
In any case this is definitely a bug in threadSelf. I will take a look tomorrow (I'm spent today).