02:19 <awygle> Aw, I missed the chance to suggest that weird ISO standard for self describing XML datasheets

02:23 <awygle> Oh it's IEEE 1451, not ISO

02:23 <ebb> sounds like retro JSON-schema

02:24 <ebb> awygle: IEEE 1451 is... "a set of smart transducer interface standards" ?

02:25 <awygle> Yep

02:25 <ebb> ah, it defines electronic datasheets

02:25 <awygle> Yep

02:25 <awygle> The XML is actually specifically a space plug and play avionics thing I guess

02:25 <awygle> "xTEDS"

02:26 <ebb> could have been xTENDS -- stick a 'Node' in there

05:51 <TD-Linux> the autobaud applet remains my most used one.

05:51 <TD-Linux> so simple but so useful

05:51 <whitequark> :D

10:11 <_whitenotifier-3> [glasgow] Failure. The Travis CI build failed - https://travis-ci.org/GlasgowEmbedded/glasgow/builds/638776232?utm_source=github_status&utm_medium=notification

19:02 <tnt> I: g.applet.interface.jtag_probe: manufacturer=0x021 (Lattice Semi.) part=0x1111 version=0x4

19:02 <tnt> double free or corruption (!prev)

19:02 <tnt> Aborted

19:02 <tnt> That's interesting :)

22:57 <whitequark> hm

22:57 <whitequark> is it during applet exit?

22:57 <whitequark> or is it in the middle of applet?

22:58 <tnt> At applet exit. But ... not every time.

22:59 <tnt> And I only ever saw it with that particular applet.

22:59 <whitequark> ok, right

22:59 <whitequark> there is a race condition in python-libusb1

23:00 <whitequark> the thing is that interpreter shutdown garbage collects objects in random order, and a library might find that for example an USB handle is collected before the transfer that needs to be cancelled

23:01 <whitequark> this caused various crashes and I should be shutting down USB before quitting in every case now

23:01 <whitequark> but maybe there's something else here

23:01 <whitequark> hm

23:01 <whitequark> actually, can you grab a backtrace/

23:01 <whitequark> ?

23:02 <tnt> https://pastebin.com/6qextVby

23:02 <tnt> Not sure how useful that is ...

23:03 <whitequark> hm wtf

23:03 <whitequark> can you get libc debug symbols?

23:04 <whitequark> actually, can you just run it under valgrind instead?

23:04 <whitequark> that will be more efficient

23:06 <tnt> ok, gimme a sec, I need to reconnect everything. (the backtrace I had done previously already ...)

23:07 <whitequark> there are only 2 native libs, bitarray and libusb

23:07 <whitequark> bitarray is shit and needs to be replaced

23:07 <whitequark> but i doubt it's the problem here

23:07 <whitequark> or... hm... jtag uses it a lot

23:07 <whitequark> so it might be

23:07 <sorear> can you test if the handle still exists, or otherwise test if global destruction is active?

23:08 <whitequark> sorear: there is a workaround that the python-libusb developer is using

23:08 <whitequark> it is extraordinarily labor intensive and hard to test

23:08 <whitequark> it works in most cases, but i agree with him that tracking down every single one is probably unrealistic

23:08 <whitequark> trying to use ctypes during interpreter shutdown is just fucked

23:09 <whitequark> doubly so locking on IO

23:09 <whitequark> I'm honestly surprised it works as well as it does, only crashing occasionally

23:13 <tnt> It's just not crashing when run under valgrind

23:13 <whitequark> lol

23:14 <whitequark> ok well I'm out of ideas

23:14 <whitequark> sorry

23:14 <whitequark> hm, wait, I have one

23:14 <tnt> Not really a problem tbh, just wanted to report.

23:15 <whitequark> try MALLOC_CHECK_=3 glasgow ...

23:16 <tnt> What's that supposed to do ? Still just print the same "free(): invalid pointer" "Aborted" when it crashes.

23:17 <whitequark> ok, no ideas then

23:17 <whitequark> it's a glibc malloc tunable

23:19 <tnt> For some reason it _much_ less frequent now that a few hours ago ... I must just have been unlucky.