Panic or segfault in Samba
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
samba (Ubuntu) |
New
|
High
|
Unassigned |
Bug Description
Continual email from root noting "Panic or segfault in Samba". Unknown if a security issue.
By 'Continual' I mean about once a day. Does seem to do it more when I'm coming across a LAN to the Samba machine.
I have one folder at root drive called 'shared' (/shared)
This folder is for users on the LAN to share items. Not sure if it matters, but all users are accessing this shared folder from a windows O/S.
Two uses accessing are using Windows XP, and a third is using Windows 7.
The bulk of the times I get the email seem to be right after [accessing/
There have been a couple of times that I have gotten the email from root, where no known accessing of the shared folder had occurred.
Here is email from root
-------
The Samba 'panic action' script, /usr/share/
was called for PID 11354 (/usr/sbin/smbd).
This means there was a problem with the program, such as a segfault.
Below is a backtrace for this process generated with gdb, which shows
the state of the program at the time the error occurred. The Samba log
files may contain additional information about the problem.
If the problem persists, you are encouraged to first install the
samba-dbg package, which contains the debugging symbols for the Samba
binaries. Then submit the provided information as a bug report to
Ubuntu by visiting this link:
https:/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_
0x00007f0d3e098c8e in waitpid () from /lib/x86_
#0 0x00007f0d3e098c8e in waitpid () from /lib/x86_
#1 0x00007f0d3e01e29e in ?? () from /lib/x86_
#2 0x00007f0d4146ff3c in smb_panic (why=<optimized out>) at lib/util.c:1123
#3 0x00007f0d414611d8 in fault_report (sig=11) at lib/fault.c:53
#4 sig_fault (sig=11) at lib/fault.c:76
#5 <signal handler called>
#6 0x00007f0d3e13c321 in ?? () from /lib/x86_
#7 0x00007f0d41445f4e in rep_strlcpy (d=0x7fffadd529f4 "", s=0x0, bufsize=256) at ../lib/
#8 0x00007f0d4147c7b4 in connections_
#9 0x00007f0d4115e13c in yield_connection (conn=0x7f0d428
#10 0x00007f0d411d3243 in close_cnum (conn=0x7f0d428
#11 0x00007f0d41164e14 in conn_close_all (sconn=<optimized out>) at smbd/conn.c:242
#12 0x00007f0d416ddd85 in exit_server_common (how=SERVER_
#13 0x00007f0d416de12e in exit_server_cleanly (explanation=
#14 0x00007f0d411ceb09 in smbd_server_
#15 0x00007f0d4147fbfe in run_events_poll (num_pfds=3, pfds=0x7f0d4287
#16 run_events_poll (ev=0x7f0d4285c520, pollrtn=<optimized out>, pfds=0x7f0d4287
#17 0x00007f0d411d01c2 in smbd_server_
#18 smbd_process (sconn=
#19 0x00007f0d416ddb8f in smbd_accept_
#20 0x00007f0d4147fbfe in run_events_poll (num_pfds=3, pfds=0x7f0d4285
#21 run_events_poll (ev=0x7f0d4285c520, pollrtn=<optimized out>, pfds=0x7f0d4285
#22 0x00007f0d4147fd9a in s3_event_loop_once (ev=0x7f0d4285c520, location=<optimized out>) at lib/events.c:349
#23 0x00007f0d41480920 in _tevent_loop_once (ev=0x7f0d4285c520, location=
#24 0x00007f0d4114e090 in smbd_parent_loop (parent=<optimized out>) at smbd/server.c:844
#25 main (argc=<optimized out>, argv=<optimized out>) at smbd/server.c:1326
A debugging session is active.
Inferior 1 [process 11354] will be detached.
Quit anyway? (y or n) [answered Y; input not from terminal]
-------
Operating Machine Info:
Operating system = Ubuntu Linux 12.04.4
Webmin version = 1.660
Time on system = Mon Mar 3 14:38:56 2014
Kernel and CPU = Linux 3.8.0-36-generic on x86_64
Processor information = Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz, 4 cores
System uptime = 3 days, 4 hours, 58 minutes
Running processes = 239
CPU load = averages 0.00 (1 min) 0.01 (5 mins) 0.05 (15 mins)
CPU usage = 0% user, 0% kernel, 1% IO, 99% idle
Real memory = 1.12 GB used, 3.56 GB total
Virtual memory = 96 kB used, 14.90 GB total
Local disk space = 46.95 GB used, 450.87 GB total
=======
Please let me know if you need more information.
Wm Lewis
Thanks for reporting this bug.
If it is possible to install apport on the system, let apport get a /var/crash/ report for this failure, and then report that with 'apport-bug /var/crash/ filename. crash', that would be great