The Samba-Bugzilla – Bug 5512
Panic with 3.2.0rc1 on Solaris10/ADDomainMember
Last modified: 2010-02-07 17:10:51 UTC
I can smbmount a testshare and display its
content, but when trying to access the files, Samba panics.
Get the Loglevel 10 smbd.log at
My initial Mail to the mailinglis is at http://marc.info/?t=121239449200001&r=1&w=2
Testparm output is:
---------------------------- 8< ----------------------------
Load smb config files from /etc/samba/smb.conf
Processing section "[testshare]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
workgroup = ZHAW
realm = ZHAW.CH
server string = "Test Datenserver mustang3"
security = ADS
use kerberos keytab = Yes
log level = 10
log file = /var/log/smbd.log
max log size = 0
load printers = No
local master = No
domain master = No
wins server = 126.96.36.199
lock directory = /var/spool/locks
delete veto files = Yes
veto files = /.AppleDB/.AppleDouble/.DS_Store/.bin/.AppleDesktop/Network Trash Folder/unix/
wide links = No
comment = Testshare
path = /var/testshare
valid users = kaph
read only = No
force create mode = 0775
force directory mode = 02775
use sendfile = Yes
---------------------------- 8< ----------------------------
*** Bug 5514 has been marked as a duplicate of this bug. ***
This entry in the log concerns me.
send_file_readX: sendfile failed for file SS2.FieldServiceManual.pdf (Bad address). Terminating
It looks like the code sendfile is broken on this platform. I'll get someone from Sun to investigate.
- setting sendfile=no doesn't help
- 3.0.30 does work
Just tried on a box that says
SunOS sunX 5.10 Generic sun4u sparc SUNW,Sun-Blade-1000
and I could not reproduce this. Hmmm.
While compiling Samba 3.2.0 again, I just discovered
lib/sendfile.c: In function `sys_sendfile':
lib/sendfile.c:187: warning: cast from pointer to integer of different size
Does this ring a bell for somebody?
Created attachment 3382 [details]
This is a backtrace of the process which paniced
I set 'panic action=99999' and ran
gdb /usr/sbin/samba --pid=<PidOfPanicedProcess>
I may be seeing the same issue. Samba 3.2.0 built using gcc 3.4.3 on Solaris 10 Sparc (SunOS techops 5.10 Generic_137111-02 sun4u sparc SUNW,Ultra-80) This server is a member server of Active Directory.
Output of testparm and level 10 log files at
Created attachment 3389 [details]
Can you try the attached patch?
(In reply to comment #7)
> I may be seeing the same issue. Samba 3.2.0 built using gcc 3.4.3 on Solaris
> 10 Sparc (SunOS techops 5.10 Generic_137111-02 sun4u sparc SUNW,Ultra-80) This
> server is a member server of Active Directory.
> Output of testparm and level 10 log files at
That one looks different. Can you also provide a backtrace given the instructions here?
(In reply to comment #8)
> Created an attachment (id=3389) 
> Can you try the attached patch?
Thanks Volker, I applied this patch, but nothing
changed. Did you see comment #5 ?
(In reply to comment #10)
> Thanks Volker, I applied this patch, but nothing
> changed. Did you see comment #5 ?
Yes, I did see comment #5. This would only apply however if you have "use sendfile = yes" activated. Can you send a new backtrace with the patch applied?
Created attachment 3392 [details]
(In reply to comment #11)
> Yes, I did see comment #5. This would only apply however if you have "use
> sendfile = yes" activated. Can you send a new backtrace with the patch applied?
OK, I just attached another backtrace made after I applied your patch.
I had to apply it by hand, btw. because 'patch -p3 <patchfile'
in source/locking didn't work.
What would have been the proper way to apply it?
Created attachment 3393 [details]
locking.c with the patch applied
Hmmm. What exact version are you running? I just tried to apply the patch, and it worked fine. I've attached the patched locking.c which comes from the 3.2.0 release.
use gpatch (GNU patch), I often saw Sun's patch fail to apply unified diff patches created by GUN diff (or by git, can't remember...)
(In reply to comment #15)
> use gpatch (GNU patch), I often saw Sun's patch fail to apply unified diff
> patches created by GUN diff (or by git, can't remember...)
Ah, thanks. That was it.
gpatch -p3 <patchfile
What does work? Could you apply the patchfile and it still dies, or does the patch cure your problem?
Pushed the fix. Thanks,
I'm very sorry having to reopen this bug, but it seems there's still some sendfile problems in 3.2.0:
While I can connect and browse shares ok, if i double click for example on a pdf file, Acroread starts but fails to open the document on the samba share.
send_file_readX: sendfile failed for file private/Arbeitszeitstatistiken/AZSt-2006.02.pdf (Bad address). Terminating
What can I do to help you find this bug?
Can you upload a new debug level 10 log with 3.2.1? The alignment-related patches went into 3.2.1, if there's a sendfile problem left we should catch that one now.
Here's the log created while running Samba 3.2.1
Doubleclicking on a PDF File from a Windows Client
yields an acrobat reader without an open file
This bug is still present in samba 3.2.7 on solaris 9 sparc.
uname -a: SunOS sambatest 5.9 Generic_112233-12 sun4u sparc SUNW,Ultra-4
Library stack is: libiconv-1.11, openssl-0.9.8j, heimdal-1.2.1, cyrus-sasl-2.1.22, openldap-0.9.8j
Compiler: gcc 3.4.5
./configure --prefix=/opt/visionet/samba --with-shared-modules=idmap_ad --with-ads --with-aio-support --with-acl-support --with-quotas --with-krb5=/opt/visionet/heimdal --with-ldap --with-winbind --with-pam --with-libiconv=/opt/visionet/iconv --with-included-popt
The relevant part of the log.smbd is:
[2009/01/13 10:32:01, 0] smbd/reply.c:send_file_readX(3236)
send_file_readX: sendfile failed for file Normal.dot (Bad address). Terminating
A log level 10 logfile is attached.
Created attachment 3867 [details]
smbd 3.2.7 log level 10 on solaris 9 sparc
did you solve the bug for you or are you working now with use sendfile = No?
(In reply to comment #26)
> @Christoph Kaegi:
> did you solve the bug for you or are you working now with use sendfile = No?
No, I didn't solve the bug. We still run Samba 3.0.30...
Just wanted to add, that this bug is still up and alive with 3.3.4.
I have to use "use sendfile = no" in order for the shares to work.
The errormessage in smbd.log is now:
[2009/04/29 13:55:02, 0] smbd/reply.c:send_file_readX(3279)
send_file_readX: sendfile failed for file print-2006.11/2006.03.06-171404.jpg (Bad address). Terminating
*** Bug 6951 has been marked as a duplicate of this bug. ***