Skip to content
This repository has been archived by the owner on Oct 3, 2022. It is now read-only.

Abort on import #77

Open
bakape opened this issue Aug 25, 2020 · 8 comments
Open

Abort on import #77

bakape opened this issue Aug 25, 2020 · 8 comments
Labels

Comments

@bakape
Copy link
Owner

bakape commented Aug 25, 2020

When thumbnailing certain files in the middle of a group of files, hydron receives a SIGABRT and crashes with one of a number of different error messages.
corrupted size vs. prev_size while consolidating
malloc(): corrupted top size
corrupted double-linked list
free(): invalid next size (normal)
Every file can be thumbnailed individually. If the import command is repeated, it will move past the point of crash but it might still crash on a later file. The order that the files are processed in seems to be important so to reproduce consistently hydron/import.go#41 should be n := 1
Both folders in the attached zip crash, I can get more examples if you like.
Debian 10, thumbnailer v2.6.4, hydron and deps up to date.

test data.zip

@bakape bakape added the bug label Aug 25, 2020
@Kamuso
Copy link
Collaborator

Kamuso commented Aug 30, 2020

I "fixed" it by setting thumbnailer.c#93 to dst->data = malloc(dst->size + 25);
so av_image_get_buffer_size must be giving the wrong size for some files. I don't know where to go from here.

@bakape
Copy link
Owner Author

bakape commented Aug 30, 2020

Why 25?

@Kamuso
Copy link
Collaborator

Kamuso commented Aug 30, 2020

It's the smallest value that worked with the test data. I tried with 100 first.

@Kamuso
Copy link
Collaborator

Kamuso commented Oct 21, 2020

I tried some imports running Hydron with Valgrind to see what's happening with memory. Running valgrind --read-var-info=yes --leak-check=no ./hydron import path shows invalid writes when importing the files that cause crashes. Pic related. Other files report no invalid writes.
valgrind output
Valgrind still reports an invalid write when using the malloc(dst->size + 25) I mentioned earlier, but malloc(dst->size + 64)
is fine.
All the bad images I've found have been jpgs with YUVJ420p colour encoding. Re-encoding them as png, or as jpg with YUVJ444p colour makes them thumbnail with no invalid writes, but not all YUVJ420p jpgs cause invalid writes.
I tried having a look at the ffmpeg source to see where the 8 bytes are coming from but I can't figure it out. Do you have any suggestions?

@Chiiruno
Copy link
Collaborator

I believe this may be an issue with webp, as well.
example_image.tar.gz
wtf.log

@bakape
Copy link
Owner Author

bakape commented Dec 17, 2020 via email

@bakape bakape closed this as completed in 717ae6e Feb 10, 2021
@bakape bakape reopened this Feb 10, 2021
@bakape
Copy link
Owner Author

bakape commented Feb 10, 2021

I might have fixed it in the commit above. As you can reproduce, could you try the fix? Will try to reproduce before and after commit myself a later this week.

@Kamuso
Copy link
Collaborator

Kamuso commented Feb 11, 2021

Still aborts. When trying to reproduce, running valgrind --read-var-info=yes --leak-check=no ./hydron import path and looking for invalid writes is more reliable than looking for crashes, by the way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants