Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault in ad_conv_v22ea_rf running dbd -f -c -t #97

Closed
atomt opened this issue Nov 7, 2017 · 5 comments
Closed

Segfault in ad_conv_v22ea_rf running dbd -f -c -t #97

atomt opened this issue Nov 7, 2017 · 5 comments

Comments

@atomt
Copy link

atomt commented Nov 7, 2017

Very old volume that was moved to netatalk 3.1.x a year ago+. It is fairly inconsistent (may have missed a dbd conversion?) and causing some errors on the clients, so to clean things up I figured I would rebuild the CNID/ea stuff. However, dbd -f -c -t /path segfaults.

I can arrange for a core and the relevant .AppleDouble out of band.

setup

Ubuntu 16.04 x86-64 (64bit)
Netatalk 3.1.11
CNID configuration is default.
Configured with:
./configure --with-tracker-pkgconfig-version=1.0 --with-init-style=systemd --with-pam-confdir=/etc/pam.d

kernel

dbd[4164897]: segfault at 6e0 ip 00007fde6ac925ca sp 00007fff30327000 error 4 in libatalk.so.18.0.0[7fde6ac80000+7b000]

GDB

(gdb) run -f -c -t /disks/archive/startrek/arkiv
Starting program: /usr/local/bin/dbd -f -c -t /disks/archive/startrek/arkiv
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b5f5ca in ad_conv_v22ea_rf (path=path@entry=0x6308f3 "Apollo_speil.psd", sp=sp@entry=0x60f7c0 <st>, vol=vol@entry=0x613310) at ad_conv.c:158
158	        EC_ZERO_LOG( copy_fork(ADEID_RFORK, &adea, &adv2,
(gdb) bt
#0  0x00007ffff7b5f5ca in ad_conv_v22ea_rf (path=path@entry=0x6308f3 "Apollo_speil.psd", sp=sp@entry=0x60f7c0 <st>, vol=vol@entry=0x613310) at ad_conv.c:158
#1  0x00007ffff7b5f9be in ad_conv_v22ea (vol=0x613310, sp=0x60f7c0 <st>, path=0x6308f3 "Apollo_speil.psd") at ad_conv.c:185
#2  ad_convert (path=0x6308f3 "Apollo_speil.psd", sp=sp@entry=0x60f7c0 <st>, vol=0x613310, newpath=newpath@entry=0x7fffffffb988) at ad_conv.c:285
#3  0x0000000000402f3e in check_adfile (fname=fname@entry=0x6308f3 "Apollo_speil.psd", newname=newname@entry=0x7fffffffb988, st=0x60f7c0 <st>)
    at cmd_dbd_scanvol.c:171
#4  0x0000000000403754 in dbd_readdir (volroot=volroot@entry=0, did=did@entry=2802515968) at cmd_dbd_scanvol.c:752
#5  0x0000000000403b75 in dbd_readdir (volroot=volroot@entry=0, did=did@entry=1056964608) at cmd_dbd_scanvol.c:786
#6  0x0000000000403b75 in dbd_readdir (volroot=volroot@entry=0, did=did@entry=536870912) at cmd_dbd_scanvol.c:786
#7  0x0000000000403b75 in dbd_readdir (volroot=volroot@entry=1, did=did@entry=33554432) at cmd_dbd_scanvol.c:786
#8  0x0000000000403d49 in cmd_dbd_scanvol (vol_in=vol_in@entry=0x613310, flags=14) at cmd_dbd_scanvol.c:863
#9  0x0000000000402313 in main (argc=<optimized out>, argv=<optimized out>) at cmd_dbd.c:292
@UUVE
Copy link

UUVE commented Mar 13, 2023

I have the same serious problem on my netatalk server running on Debian 11.6.

My Setup
Debian 11.6 x86-64 (64bit)
Netatalk 3.1.14 (I've made a new Debian package using the official Debian Package as guideline, appliyng the relevant patches)
CNID configuration is the default.

My server undergone an upgrade from netatalk v.2.2.x several years ago and is is over 10 years that Netatalk is serving my files (transferred from a Mac OS X machine acting as server). At the time of switching I also switched to "ea = samba" configuration option in afp.conf leaving netatalk to convert on the fly the apple double files to ._* files. Now, wishing to share the same volumes with Samba I decided to consolidate all the files, getting rid of the .AppleDouble directories still present, via the utility dbd (dbd -vc <path_to_the_shared_volume>.

The above command terminate suddenly with segment fault. This seems to happen when some apple double files are processed. Whenever this happens, looking at the file that dbd was processing, I see that only a portion of the offending file has been converted to the corresponding ._<file_name>. In particular, the size of the partially converted file is always 82 bytes.

If I try to select the offending file (or folder, which can also be a package) with a Mac OS client, netatalk panics and the client's Finder constantly shows a spinning cursor in the window, however I navigate through the server files, forcing myself to terminate netatalk on the server and restart it. In /var/log/syslog this is the output of netatalk:
Mar 13 20:51:02 server1 afpd[630107]: ad_header_read_ea("/shares/Office/Users"): invalid metadata EA this is now being treated as a fatal error. if you see this log entry, please file a bug ticket with your upstream vendor and attach the generated core file. Mar 13 20:51:02 server1 afpd[630107]: ad_open_hf_ea: unexpected: Invalid argument Mar 13 20:51:02 server1 afpd[630107]: =============================================================== Mar 13 20:51:02 server1 afpd[630107]: INTERNAL ERROR: Signal 11 in pid 630107 (3.1.14) Mar 13 20:51:02 server1 afpd[630107]: =============================================================== Mar 13 20:51:02 server1 afpd[630107]: PANIC: internal error Mar 13 20:51:02 server1 afpd[630107]: BACKTRACE: 12 stack frames: Mar 13 20:51:02 server1 afpd[630107]: #0 /usr/lib/x86_64-linux-gnu/libatalk.so.18(netatalk_panic+0x35) [0x7fcf109f0b15] Mar 13 20:51:02 server1 afpd[630107]: #1 /usr/lib/x86_64-linux-gnu/libatalk.so.18(+0x32c5c) [0x7fcf109f0c5c] Mar 13 20:51:02 server1 afpd[630107]: #2 /lib/x86_64-linux-gnu/libc.so.6(+0x38d60) [0x7fcf1043dd60] Mar 13 20:51:02 server1 afpd[630107]: #3 /usr/lib/x86_64-linux-gnu/libatalk.so.18(ad_rebuild_adouble_header_osx+0x63) [0x7fcf109d1d63] Mar 13 20:51:02 server1 afpd[630107]: #4 /usr/lib/x86_64-linux-gnu/libatalk.so.18(ad_flush+0x387) [0x7fcf109d2247] Mar 13 20:51:02 server1 afpd[630107]: #5 /usr/lib/x86_64-linux-gnu/libatalk.so.18(+0x135f8) [0x7fcf109d15f8] Mar 13 20:51:02 server1 afpd[630107]: #6 /usr/lib/x86_64-linux-gnu/libatalk.so.18(ad_convert+0x2ee) [0x7fcf109d192e] Mar 13 20:51:02 server1 afpd[630107]: #7 /usr/sbin/afpd(+0x1f3b8) [0x55f51fcaf3b8] Mar 13 20:51:02 server1 afpd[630107]: #8 /usr/sbin/afpd(afp_over_dsi+0x5a0) [0x55f51fca0460] Mar 13 20:51:02 server1 afpd[630107]: #9 /usr/sbin/afpd(main+0x9c4) [0x55f51fc9e3b4] Mar 13 20:51:02 server1 afpd[630107]: #10 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fcf10428d0a] Mar 13 20:51:02 server1 afpd[630107]: #11 /usr/sbin/afpd(_start+0x2a) [0x55f51fc9e70a] .... Mar 13 20:51:40 server1 afpd[631878]: Login by <my_username> (AFP3.4) Mar 13 20:51:40 server1 afpd[631878]: afp_disconnect: trying primary reconnect Mar 13 20:51:40 server1 afpd[2954653]: Reconnect: no child[631468]

@rdmark
Copy link
Member

rdmark commented Aug 19, 2023

@UUVE Your issue should have been resolved with the fix for #368 -- if you're able to build netatalk from the main branch sources you can test it right away.

For the record, your stack trace looks slightly different from what I have seen from other reports, so I'm extra curious to hear back about your test results.

@rdmark
Copy link
Member

rdmark commented Aug 19, 2023

@atomt While it's been almost 6 years since your report so I don't anticipate your watching this ticket, but if you have your netatalk server active still, we have recently made major updates to the appledouble validation logic in libatalk. It might be valuable to try rebuilding the database again.

@rdmark
Copy link
Member

rdmark commented Aug 30, 2023

Closing this ticket for now as the code has changed. Please file a new issue ticket if a similar error persists.

@rdmark rdmark closed this as completed Aug 30, 2023
@UUVE
Copy link

UUVE commented Aug 30, 2023

@UUVE Your issue should have been resolved with the fix for #368 -- if you're able to build netatalk from the main branch sources you can test it right away.

For the record, your stack trace looks slightly different from what I have seen from other reports, so I'm extra curious to hear back about your test results.

Thank you very much rdmark,
I'm very busy right now and will wait for the next Netatalk release to build a new Debian installation package and test if the changes fixed the problem.

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

No branches or pull requests

3 participants