- This topic has 3 replies, 3 voices, and was last updated 15 years, 10 months ago by
.
-
Posts
-
I haven’t upgraded to the latest nightly for maybe 12 months…. I compiled and installed 1528 today and was greeted with a segmentation fault when I ran it.
The problem was that my /etc/mt-daapd.conf included the following line:
plugin_dir = /usr/lib
I recall encountering a problem way back with this, and I think I fixed it by explicitly providing the path to each library file. In any case, the problem went away when I made plugin_dir point to /usr/lib/mt-daapd – which is where the new library files were anyway.
I’m guessing that mt-daapd is trying to load *every* file in the configured library directory – ie hundreds of them when my conf file was broken and pointing to the wrong plugin_dir.
Yes – I know the segmentation fault was because of my configuration error. Probably even stupid configuration errors should get flagged with something more meaningful than a segmentation fault! 😉
I haven’t gone looking at the source code so I’m not sure of the best way to fix it. Do you assume a max / static number of library files? (… and if so, is there a test you can add to see whether the directory contains more than this number of loadable modules?)
Stefan
@skellert wrote:
I haven’t upgraded to the latest nightly for maybe 12 months…. I compiled and installed 1528 today and was greeted with a segmentation fault when I ran it.
The problem was that my /etc/mt-daapd.conf included the following line:
plugin_dir = /usr/lib
I recall encountering a problem way back with this, and I think I fixed it by explicitly providing the path to each library file. In any case, the problem went away when I made plugin_dir point to /usr/lib/mt-daapd – which is where the new library files were anyway.
I’m guessing that mt-daapd is trying to load *every* file in the configured library directory – ie hundreds of them when my conf file was broken and pointing to the wrong plugin_dir.
Yes – I know the segmentation fault was because of my configuration error. Probably even stupid configuration errors should get flagged with something more meaningful than a segmentation fault! 😉
I haven’t gone looking at the source code so I’m not sure of the best way to fix it. Do you assume a max / static number of library files? (… and if so, is there a test you can add to see whether the directory contains more than this number of loadable modules?)
Stefan
No, I just walk through and see if they export the symbols I expect. What platform is this? Seems like I tried to replicate it once before and couldn’t, so I’m wondering if it’s platform dependant, or if there is some library you have that exports a function called “plugin_info”, which is what I’m checking for. Maybe I need to export some magic number or something to verify that it’s really a mt-daapd plugin.
— Ron
Ron, I’ve experienced the problem both on FC5 and FC6. (My development system is FC6, the stable fileserver is FC5).
I shall send you a directory listing of the offending directory.
Stefan
I had the same problem on Fedora 7 (installed with mt-daapd-0.2.4-2.fc6.mf.i386.rpm)
Could not find what the problem was, at first I thought that the filenames or files where corrupt. and giving the error “Segmentation fault”The strange thing was that it wasn’t hanging on the same file.
As a test I removed the file /var/cache/mt-daapd/songs.gdb and run mt-daapd -d9 -f again… It is still running…
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.