Mp3tag shut down after viewing multiple songs

Yes, I also see that — thanks for looking into it. But there are others where it's happening when strings get deallocated. It's really mysterious.

So I guess something corrupts the heap beforehand and then it crashes there...

1 Like

Can you check again with this internal version and send any crash dumps along my way :sweat_smile:

thanks, I reproduced the bug on the new version (503.1 KB)

OK, thanks. You're probably already an expert in reproducing this: can you describe the minimal steps that you're doing to trigger this?

Lol yes

Example #1-

  1. Press right click on folder
  2. Select "Mp3tag" button in options window
  3. Press right click on first song
  4. Select "Extended Tags..." button
  5. Press "> >" button multiple times until crash might occur (usually around song 6/7/10).

Example #2-

  1. Select all songs in folder
  2. Press right click on songs
  3. Select "Mp3tag" button in options window
  4. Press right click on song in the middle of the list
  5. Select "Extended Tags..." button
  6. Press "< <" button multiple times until crash might occur (usually once getting closer to the beginning).

Please let me know if it helps, or I should get a screen recording.

This helps, thank you! Except that it doesn't crash here :slight_smile: I'll continue trying...

1 Like

Okay, apparently there was an important difference between yesterday and today.
Yesterday I used my laptop and today I used my home pc.

I just ran v3.06c on my laptop and was able to reproduce the crash and generate a full dump rather than a minidump: Hopefully it will help.


Any luck finding the bug? Can I help in any way?

Unfortunately, no luck in finding the bug. It's crashing when calling the destructor of a certain class, but I don't see how the memory got corrupted in the first place.

Thanks for the full dump! It's the first time I've received something like that and it's a real luxury for debugging :smiley:

1 Like

Sure thing!

A tool called GFlags should be able to detect the corruption when it happens. I'll try to run it and see what I can find without symbols or source code. I'll let you know if I find any lead.

1 Like

I used GFlags, and it seems the corruption does happen when working with paths.

Here is a minidump of the corruption: (239.8 KB)
If you need a full dump again, let me know.

1 Like

@Florian, if I'm not mistaken you are calling PathCompactPath with a buffer smaller than MAX_PATH + 1 characters (see documentation here: PathCompactPathW function (shlwapi.h) - Win32 apps | Microsoft Docs), and in this case (with the specific path and the specific window width) a buffer overflow occurs.


Are you a wizard? :exploding_head: :innocent: It's really amazing what you've done here and I'm full of awe regarding your skills.

This is the relevant section, and you're right, the buffer is too small.

const auto count = ::_tcslen(filePath) + 1;
std::vector<TCHAR> buffer(count);

::_tcscpy_s(, count, filePath);
::PathCompactPath(dc,, windowRect.Width() -;

I'll fix right away and upload a new internal version soon.


This is the new internal version containing the fix for the bug you've spotted:

I'm really curious now :smiley:

I tried to reproduce the bug on version 306c2 and it was fixed!
Thank you so much to everyone who commented, worked and made an effort to resolve this.
Special thanks to @Prilkop for spotting it!


It isn't reproduced here too.

I think we did it! :smiley:


Really cool :raised_hands: Thank you both for helping with that :pray:

@Prilkop, that's really amazing what you did there. Thanks a lot!

1 Like

No problem!
Thank you @Florian for creating and maintaining such a cool and useful tool for such a long time!

Happy to help! :slight_smile:

1 Like

I've now fixed that officially with Mp3tag v3.06d.

Thank you!