Date: Sat, 18 Apr 2020 04:09:26 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 245715] net/samba410: smbd[XXX]: INTERNAL ERROR: Signal 11 in pid XXX (<version>) Message-ID: <bug-245715-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245715 Bug ID: 245715 Summary: net/samba410: smbd[XXX]: INTERNAL ERROR: Signal 11 in pid XXX (<version>) Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: timur@FreeBSD.org Reporter: kumba@gentoo.org Assignee: timur@FreeBSD.org Flags: maintainer-feedback?(timur@FreeBSD.org) net/samba410 built from ports with most features turned off (just AESNI, SYSLOG, UTMP, GSSAPI_BUILTIN, and ZEROCONF_NONE) will periodically crash wi= th a SIGSEGV. The trigger seems to be if I store a couple of icon (*.ico) files= on the exported samba share and then try to use those icons in a shortcut obje= ct (*.lnk), and then try to trigger Windows to refresh its icon cache (by executing "C:\Windows\System32\ie4uinit.exe -show"). Furthermore, these shortcut objects have to be stored in a "quick launch" toolbar folder that I have added to my Windows taskbar (right-click -> Toolbars -> New Toolbar -> ...). Under that setup, by re-running the icon cache refresh command, one or more= of the shortcut objects will lose their icons and default to the blank document icon stred in "C:\Windows\System32\shell32.dll". When that happens, if I t= hen try to manually reset the icon by reselecting it, I may, or may not, get an error stating that Windows can no longer find the icon on the remote samba share path. Sometimes, when re-selecting the icon file in the file dialog, Windows will then claim that it cannot read the icon file. When one of these two events happens, it MAY indicate that the smbd process= on the FreeBSD server has SIGSEGV'ed. But not always. You kinda have to play around with it to trigger it. It seems running the icon cache refresh comm= and several times, with a small pause between each run, has the best chance of triggering it. When it does happen, this is the output I get (hostname scrubbed): Apr 17 21:59:12 foo smbd[97026]: [2020/04/17 21:59:12.993900, 0] ../../lib/util/become_daemon.c:136(daemon_ready) Apr 17 21:59:12 foo smbd[97026]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.766807, 0] ../../lib/util/fault.c:79(fault_report) Apr 17 22:00:37 foo smbd[164]:=20=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.767238, 0] ../../lib/util/fault.c:80(fault_report) Apr 17 22:00:37 foo smbd[164]: INTERNAL ERROR: Signal 11 in pid 164 (4.10= .14) Apr 17 22:00:37 foo smbd[164]: If you are running a recent Samba version,= and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Repor= ting Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.767282, 0] ../../lib/util/fault.c:86(fault_report) Apr 17 22:00:37 foo smbd[164]:=20=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.767304, 0] ../../source3/lib/util.c:824(smb_panic_s3) Apr 17 22:00:37 foo smbd[164]: PANIC (pid 164): internal error Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.767983, 0] ../../lib/util/fault.c:265(log_stack_trace) Apr 17 22:00:37 foo smbd[164]: BACKTRACE: 6 stack frames: Apr 17 22:00:37 foo smbd[164]: #0 0x36b07d6eaa77 <log_stack_trace+0x37> = at /usr/local/lib/samba4/libsamba-util.so.0 Apr 17 22:00:37 foo smbd[164]: #1 0x36b085ee512d <smb_panic_s3+0x4d> at /usr/local/lib/samba4/libsmbconf.so.0 Apr 17 22:00:37 foo smbd[164]: #2 0x36b07d6ea867 <smb_panic+0x17> at /usr/local/lib/samba4/libsamba-util.so.0 Apr 17 22:00:37 foo smbd[164]: #3 0x36b07d6eac4e <log_stack_trace+0x20e>= at /usr/local/lib/samba4/libsamba-util.so.0 Apr 17 22:00:37 foo smbd[164]: #4 0x36b07d6ea849 <fault_setup+0x59> at /usr/local/lib/samba4/libsamba-util.so.0 Apr 17 22:00:37 foo smbd[164]: #5 0x36b0b6a593c0 <_pthread_sigmask+0x530= > at /lib/libthr.so.3 Apr 17 22:00:37 foo smbd[164]: [2020/04/17 22:00:37.768103, 0] ../../source3/lib/dumpcore.c:310(dump_core) Apr 17 22:00:37 foo smbd[164]: unable to change to %N.core Apr 17 22:00:37 foo smbd[164]: refusing to dump core It also seems that I can trigger this crash more often under the newly-mint= ed net/samba411 port, but I did not extensively test that before falling back = to net/samba410. I understand if that is somewhat convoluted, and it WILL require a Windows system to actually try and test for this, but I don't have much else to off= er.=20 Browsing the share normally from Windows Explorer works fine and icons cache and load fine from virtually any other place in Windows EXCEPT from a short= cut object (*.lnk) in a toolbar added to the taskbar. I don't know if there is something different about how shortcuts in a toolbar folder added to the taskbar behave differently when fetching their icon resources or what. I've tried turning the Samba logging level up to 7, but that did not add any additional context to the above crash log. I also tried attach gdb to the parent process, but the crashing process is some child process that is spaw= ned only when doing file operations, and I am not sure how to trace that. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-245715-7788>