Crashes while scanning library

[kithrup]

Thread 17 Crashed:: Dispatch queue: TeslaTunes subprocessing queue :: NSOperation 0x7f9edfe6c620 (QOS: LEGACY) 0 0x000000010052626c void std::1::tree_left_rotatestd::1::tree_nodebase<void*>(std::1::tree_nodebase<void>_) + 28 1 0x0000000100526234 void std::1::tree_balance_after_insert<std::1::tree_nodebase<void>_>(std::1::tree_nodebase<void>_, std::1::tree_nodebase<void>_) + 916 2 0x0000000100525e48 std::1::tree<std::1::value_type<TagLib::String, int>, std::1::map_value_compare<TagLib::String, std::1::value_type<TagLib::String, int>, std::1::lessTagLib::String, true>, std::1::allocator<std::1::value_type<TagLib::String, int> > >::insert_node_at(std::1::tree_nodebase<void>_, std::1::tree_nodebase<void>_&, std::1::tree_nodebase<void>_) + 504 3 0x0000000100523cb7 std::1::map<TagLib::String, int, std::1::less, std::1::allocator<std::_1::pair<TagLib::String const, int> > >::operator[](TagLib::String const&) + 1575 4 0x0000000100523360 TagLib::Map<TagLib::String, int>::insert(TagLib::String const&, int const&) + 80 5 0x00000001005215b9 TagLib::ID3v1::genreMap() + 201 6 0x00000001005216a9 TagLib::ID3v1::genreIndex(TagLib::String const&) + 25 7 0x00000001005208d1 TagLib::ID3v1::Tag::setGenre(TagLib::String const&) + 33 8 0x000000010063b6e9 TagLib::Tag::duplicate(TagLib::Tag const, TagLib::Tag*, bool) + 1993 9 0x000000010051a051 TagLib::MPEG::File::save(int, bool, int, bool) + 689 10 0x0000000100519d86 TagLib::MPEG::File::save(int, bool, int) + 54 11 0x0000000100519d3f TagLib::MPEG::File::save(int, bool) + 47 12 0x0000000100519d00 TagLib::MPEG::File::save(int) + 32 13 0x0000000100519cca TagLib::MPEG::File::save() + 26 14 0x000000010063ff50 TagLib::FileRef::save() + 144 15 net.loci.TeslaTunes 0x0000000100499102 -[CopyConvertDirs twiddleTags:withPlaylist:] + 1906 16 net.loci.TeslaTunes 0x000000010049a8e3 59-[CopyConvertDirs copyWithSource:Destination:withPlaylist:]_block_invoke + 947 17 com.apple.Foundation 0x00007fff9684d7d7 __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK + 7 18 com.apple.Foundation 0x00007fff9684d495 -[NSBlockOperation main] + 100 19 com.apple.Foundation 0x00007fff9684bb7a -[__NSOperationInternal _start:] + 654 20 com.apple.Foundation 0x00007fff96847b64 __NSOQSchedule_f + 194 21 libdispatch.dylib 0x00007fff9047640b _dispatch_client_callout + 8 22 libdispatch.dylib 0x00007fff9047b03b _dispatch_queue_drain + 754 23 libdispatch.dylib 0x00007fff90481707 _dispatch_queue_invoke + 549 24 libdispatch.dylib 0x00007fff90479d53 _dispatch_root_queue_drain + 538 25 libdispatch.dylib 0x00007fff90479b00 _dispatch_worker_thread3 + 91 26 libsystem_pthread.dylib 0x00007fff890564de _pthread_wqthread + 1129 27 libsystem_pthread.dylib 0x00007fff89054341 start_wqthread + 13

No clue (yet) what's going on, I haven't tried building it myself.

[tattwamasi]

Does this happen every time for you or only occasionally? If every time, any way you can narrow it down to a particular song? Or maybe a combination of options in terms of the tagging modifications, since it looks like the error occurred in the taglib library when saving modified tags.
This is an outside library that I've had issues with before (probably all, definitely mostly my fault - it's been a great help as a library) and its proven a little tricky to track down where the mistakes are. I'll fix it if I can find it 😀

[kithrup]

Every time now.

I haven’t figured out how to narrow it down to a particular song. What I do know is that it worked earlier, but then I changed the set of playlists (because items were missing from the thumb drive that I know were in my music library).

I figured out there was an outside library when I cloned the code and tried to build it :).

Sean.

On Apr 10, 2016, at 11:08 AM, tattwamasi notifications@github.com wrote:

Does this happen every time for you or only occasionally? If every time, any way you can narrow it down to a particular song? Or maybe a combination of options in terms of the tagging modifications, since it looks like the error occurred in the taglib library when saving modified tags.

This is an outside library that I've had issues with before (probably all, definitely mostly my fault - it's been a great help as a library) and its proven a little tricky to track down where the mistakes are. I'll fix it if I can find it 😀

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

[tattwamasi]

The libraries should show in the project file, but you'll have to grab and build them yourself if you want to build from source. I think the only non apple code used is the mp4v2 lib and taglib. Also sparkle though you could comment that out for your purpose. They are all also on github. I had to fix the framework build step on taglib manually, but I think they have it building properly now. Not sure if taking the time to get it building is faster than finding a minimal bug reproducing strategy that I can use, but I welcome your energy 😄

How much you want to deal with this is of course up to you, but if you can note how you make it crash now, then start splitting up the list of songs to find a minimal set that causes it, or get down to one sample file you can provide, I can get into it more. Was there more to the crash message, maybe above the thread 17 crashed first line?

[kithrup]

Exporting all my music, with no playlists, works.

Which is good, that means I don’t think I have to narrow it down to a particular song. But it does mean it doesn’t like one of my playlists.

But since I have a much smaller number of playlists than songs, that’s much easier to track down :).

I’ll let you know when I figure out which playlist it is.

Sean.

[kithrup]

So I’ve not had a huge lot of success reproducing the crash, but I did run into … an osx bug.

A file name such as "07-Comedy Gold-Cast of Galavant-Galavant (Original Soundtrack).m4a" causes the MS-DOS FS in Mac OS X to get … confused. To the point that I had to reformat the drive to get around it.

I’ve filed a bug with Apple and directly pinged the people who would work on it, but also letting you know.

Weird weird weird.

Sean.

On Apr 10, 2016, at 11:29 AM, tattwamasi notifications@github.com wrote:

The libraries should show in the project file, but you'll have to grab and build them yourself if you want to build from source. I think the only non apple code used is the mp4v2 lib and taglib. Also sparkle though you could comment that out for your purpose. They are all also on github. I had to fix the framework build step on taglib manually, but I think they have it building properly now. Not sure if taking the time to get it building is faster than finding a minimal bug reproducing strategy that I can use, but I welcome your energy 😄

How much you want to deal with this is of course up to you, but if you can note how you make it crash now, then start splitting up the list of songs to find a minimal set that causes it, or get down to one sample file you can provide, I can get into it more. Was there more to the crash message, maybe above the thread 17 crashed first line?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

[tattwamasi]

Thanks for the ongoing updates. That does seem strange, re: the filename, but I'm guessing that's independent of the crash? If it's not and is recreatable with that name, then it's obviously an error checking bug on my end, but I thought I had those all handled.
What I expect is it is most likely is a race condition threading bug. I feel like I probably still have some of those in the code, perhaps related to me understanding lifetime issues with TagLib (which is where it seems to blow up mostly in these hard to reproduce cases). TagLib itself has seen quite a few updates lately too, so it's possible it's actually an issue with that library. Regardless, would love to find it if it is either a threading issue or a data validation issue.

[kithrup]

On Apr 21, 2016, at 11:59 AM, tattwamasi notifications@github.com wrote:

That does seem strange, re: the filename, but I'm guessing that's independent of the crash? If it's not and is recreatable with that name, then it's obviously an error checking bug on my end, but I thought I had those all handled.

Correct, but I think it does explain how I ended up with duplicated playlist entries on the Tesla — I think it saw the long and short filenames, and treated them separately.

What I expect is it is most likely is a race condition threading bug. I feel like I probably still have some of those in the code, perhaps related to me understanding lifetime issues with TagLib (which is where it seems to blow up mostly in these hard to reproduce cases). TagLib itself has seen quite a few updates lately too, so it's possible it's actually an issue with that library. Regardless, would love to find it if it is either a threading issue or a data validation issue.

What I did for testing was to eliminate all of the playlist selections, then doing one at a time. When all that worked, I then selected all of them, and … it still worked. oy.

Sean.

[tattwamasi]

Interesting re: duplicate playlists. Strange filename behavior though - new to me.

When you say short filenames, do you mean the mangled 8.3 type old msdos filenames? Aren't you using FAT32 on your drive? I don't think I've ever seen it make 8.3 names on FAT32 or any more modern fs option, and I've never seen it return mangled names from the read directory calls I use to compare the names.

I wouldn't be surprised if I have some bad characters allowed edge logic missing in the filename routines for the cases where I actually change the filenames - I've added characters to translate as I've discovered them.

Out of curiosity, when testing, did you change your genre mapping or other "tag twiddling" options, or did it work with all playlists on a freshly empty drive in the same way it originally crashed with all playlists on a fresh drive? If the latter, then unfortunately starts to sound more like a threading/race issue, though I'd love for it to be a TagLib/data validation error (easier to find!). I did see that TagLib has fixed a bunch of crash errors in recent commits, so I may do a fresh build with their current beta release.

[kithrup]

On Apr 21, 2016, at 12:13 PM, tattwamasi notifications@github.com wrote:

Interesting re: duplicate playlists. Strange filename behavior though - new to me.

Me too, and that was my job :).

When you say short filenames, do you mean the mangled 8.3 type old msdos filenames? Aren't you using FAT32 on your drive? I don't think I've ever seen it make 8.3 names on FAT32 or any more modern fs option, and I've never seen it return mangled names from the read directory calls I use to compare the names.

There’s a mapping from mangled filename to long filename; it’s possible to get so confused that this shows up as two entries (depending on the implementation). Then it would look at the metadata in the file to present the real names.

Just a guess. Since I reformatted the thumb drive several times now, I can’t tell for sure :).

Out of curiosity, when testing, did you change your genre mapping or other "tag twiddling" options, or did it work with all playlists on a freshly empty drive in the same way it originally crashed with all playlists on a fresh drive? If the latter, then unfortunately starts to sound more like a threading/race issue, though I'd love for it to be a TagLib/data validation error (easier to find!). I did see that TagLib has fixed a bunch of crash errors in recent commits, so I may do a fresh build with their current beta release.

No, I went from reliably crashing to no crashing, simply by changing the playlist settings. I think, anyway.

There are some more options I can twiddle with, and I’ll try those.

Sean.

[tattwamasi]

Hate closing this since it isn't really handled, but time has moved on, there are new libraries used, new OS releases, etc. If anything else pops up that seems like this same issue, will reopen it.