occ music:scan segfaults #600
Comments
|
Weird, I haven't seen that happen. Is there anything in nextcloud.log? When you say that scanning works for a while, do you mean that it successfully scans some audio files (names of the audio files are printed to the console) and then the crash happens? If you use |
|
Yes, it first scans for a while printing the mp3s found. After the segfault nothing more is scanned when I give the same command again. I now experienced that after a couple of hours the scanning goes further beyond the point it segfaults before - but only to segfault again after a while... |
|
Did you close this issue by accident? From the log extract, it seems like the file pointer passed to the GetID3 library was null. This would happen if the Nextcloud framework cannot open a file for any reason. Is it possible that there is some kind of out-of-sync situation between the internal book-keeping of the Nextcloud core and the actual contents on the disk? I probably should add some kind of sanity check to the Music app to ensure that failing to open one (or several) files wouldn't break the whole scanning process. |
|
Ahhrg, closed it by accident - not the first time on github :-) |
|
Just realized, that you want me to reset the database. Done that and scanning - will take a while... |
|
No success - segfault. At the same point... |
|
The scanning runs since three hours without segfault. I'm guessing that a file size of 0 was the problem. From the users point of view a warning would be fine |
|
Another kind of exception occured: Exception trace: music:scan [--all] [--debug] [--clean-obsolete] [--] [<user_id>]... ` |
|
Segfault again - 0 byte file again. To me it looks like a very strong hint: 0 byte files are evil :-) |
|
I created a 0-byte file, named it with suffix mp3, uploaded it to Nextcloud, but this file was scanned successfully by the Music app. Maybe the crash happens only with external storage. Another difference was that I'm using Nextcloud 12.0.3.3. |
|
Ok, I'll do the same today evening and will also try a 0 byte file on a non-external storage. |
|
I have exactly the same issue on my nextcloudpi 16. Has someone found the root cause? |
|
@v0ku Nope, no root cause has been identified. Are you using external storage like the original reported was? Can you spot the file where the scanning breaks? Is there anything out of the ordinary with that file? |
|
Hi, I identified 2x files in total which I was able to isolate. Got my library imported now. These files look pretty normal and different. No idea what might be the reason. Do you want them?
|
|
Sure, if you can share those, I can check if I can reproduce the problem. You can find my email in my profile. |
|
@v0ku So were you going to share those files with me? |
|
Based on the errors shown in the logs attached to this issue, this might actually be a duplicate to #123 which got fixed in Music app v0.14.0. |
|
@paulijar Still segfault on 0 byte file on external storage... |
|
Same here on Nextcloud 20.0.4 with Music 0.17.3. My external storage is an SMB share, so I originally thought something was up with the file being read through the share or something similar, but looking at the actual file in a terminal directly on the filesystem it is also 0B in size. I suspect that the folder for this file (and the others that I ran into which I removed) was originally a soft link to another filesystem, since I have moved files into my normal music folder and then linked them to the previous place as to not break references. And indeed this particular song can be found in my normal music directory. But looking at the file and folder doesn't indicate that it is a broken link or anything. I have however migrated the parent folder its in to a new filesystem on a larger drive (using rsync) in the past. Maybe that somehow converted the link into a normal directory? But in another case I had I'm pretty sure it was not a link originally, so this might be a red herring. |
|
getting segfault with occ scan:music --all as below, I tried reset database without luck, any ideas? ValueError: fread(): Argument #2 ($length) must be greater than 0 in /var/www/html/nextcloud/apps/music/3rdparty/getID3/getid3/getid3.php:2215 |
|
@rarealphacat When scanning with |
|
@paulijar Thanks! I found the problematic file but its not a 0-byte file. Sending the file over now. |
|
@rarealphacat Thanks, I got the file. For me, this doesn't cause a segmentation fault but I do see a warning logged like |
- Don't try to analyze 0-byte files as that apparently causes a segmentation fault on (some) SMB setups - Catch all exceptions and errors from the getID3 library so that hitting a bug on one file wouldn't stop the whole scan process refs #600
|
A fix for the invalid length parameter being passed to Furthermore, I have made a fix of not even attempting to analyze 0-byte files, as that apparently still causes problems for some systems. It's not like we would be getting any metadata from such files, anyway. |
|
The updated getID3 library is now released as part of Music v1.5.0. Likewise, this version no longer tries to scan 0-byte files. Hence, I believe that all the cases reported here should be fixed now. Please open a new issue if you still see any problems like this. |
Hi,
I'm trying to scan my music collection and after a while I'm getting a segmentation fault (german message: Speicherzugriffsfehler)
command given is:
sudo -u wwwrun php occ music:scan -vv --clean-obsolete userxyzscanning works for a while, then segmentation fault follows
giving the same command again results in segmentation fault at once.
Scanning for other users works for a while but stops also with a segfault and further behaviour see above.
I'm using Nextcloud 12.0.4
Any hints?
Regards
Juergen
The text was updated successfully, but these errors were encountered: