When using load printers = yes. Samba segfaults. More information can be found at the following: http://bugs.launchpad.net/bugs/330626 PANIC (pid 907): internal error BACKTRACE: 13 stack frames: #0 smbd(log_stack_trace+0x1c) [0x7f83678af5cd] #1 smbd(smb_panic+0x5b) [0x7f83678af6db] #2 smbd [0x7f836789cdad] #3 /lib/libpthread.so.0 [0x7f8365e7d080] #4 /lib/libc.so.6(strlen+0x30) [0x7f8364451c60] #5 /lib/libc.so.6(_IO_vfprintf+0x3dbe) [0x7f836441a75e] #6 /lib/libc.so.6(__vasprintf_chk+0xd0) [0x7f83644cfd80] #7 /lib/libc.so.6(__asprintf_chk+0x83) [0x7f83644cfca3] #8 smbd(get_print_db_byname+0x508) [0x7f83678dc343] #9 smbd(print_backend_init+0x7d) [0x7f83678c8fec] #10 smbd(main+0xa25) [0x7f83677932d1] #11 /lib/libc.so.6(__libc_start_main+0xe6) [0x7f83643ef5a6] #12 smbd [0x7f8367791d89] smb_panic(): calling panic action [/usr/share/samba/panic-action 907]
Can you please recompile with -g and provide a full backtrace using gdb? I can't reproduce that here. Please also try a run under valgrind. Thanks, Volker
Hi Volker, It's trivially reproducible here with the Ubuntu package if cups is not running when trying to start smbd and a default [printers] share defined.
Repeating myself: Can you please recompile with -g and provide a full backtrace? I can not reproduce it here. And, by the way, Linux != Ubuntu, i.e. I don't have access to the Shuttleworth Linux. Volker
I mention Ubuntu explicitly so that it's clear this is being done with the Ubuntu package and it doesn't come as a surprise later that this wasn't done with the pristine upstream source. Indeed, even though the bug is trivially reproducible with the 2:3.3.0-3ubuntu2 build of samba, it's not reproducible at all with the Debian 2:3.3.0-3 build, which shouldn't have any relevant differences at all. So I'm still working on isolating the bug here.
Thanks :-) Sorry for being a bit rude, but your comment arrived like "Hey, you're too stupid to reproduce this trivially obvious one..." on my side :-) Volker
Key difference between the two builds: Debian builds with --disable-pie, Ubuntu does not. Still digging; will try to get a meaningful backtrace, and also check whether this is specific to the Ubuntu toolchain.
same problem if building with --enable-pie on Debian. Sorry, no better backtrace forthcoming; apparently, Debian's gdb can't get a backtrace at all from a -pie executable, and Ubuntu's gdb won't give any details about local variables. (gdb) bt full #0 0x00007f5ebbd6ec60 in strlen () from /lib/libc.so.6 No symbol table info available. #1 0x00007f5ebbd3775e in vfprintf () from /lib/libc.so.6 No symbol table info available. #2 0x00007f5ebbd5f07f in vasprintf () from /lib/libc.so.6 No symbol table info available. #3 0x00007f5ebbd3e078 in asprintf () from /lib/libc.so.6 No symbol table info available. #4 0x00007f5ebf1f6876 in get_print_db_byname () from /home/devel/samba/build-area/samba-3.3.0/source/bin/smbd No locals. #5 0x00007f5ebf1e780e in print_backend_init () from /home/devel/samba/build-area/samba-3.3.0/source/bin/smbd No locals. #6 0x00007f5ebf0b0009 in main () from /home/devel/samba/build-area/samba-3.3.0/source/bin/smbd No locals. Since there's an assert in get_print_db_byname() to explicitly check for a NULL printername, I guess printername isn't null, but is nevertheless corrupted somehow.
Please close this bug as invalid. The issue is with a Debian patch that's missing a function prototype, combined with Ubuntu's building with -fPIE; not an upstream samba bug.
Thanks for the hint. Which patch is it? I'd just like to know which missing prototype can cause this failure. Volker
The fhs-filespaths-debatable.patch, with a missing prototype for cache_path().
Ah, ok. Got it. It's the asprintf() in printing_db(), right? This returns 32 bit for cache_path() where on a 64-bit box this is, well, 64 bit. And with just 32 bit the printername later is NULL. Right? Volker
closing, as requested