Bug 245715 - net/samba410: smbd[XXX]: INTERNAL ERROR: Signal 11 in pid XXX (<version>)
Summary: net/samba410: smbd[XXX]: INTERNAL ERROR: Signal 11 in pid XXX (<version>)
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Timur I. Bakeyev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-18 04:09 UTC by Joshua Kinard
Modified: 2020-04-18 04:09 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (timur)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard 2020-04-18 04:09:26 UTC
net/samba410 built from ports with most features turned off (just AESNI, SYSLOG, UTMP, GSSAPI_BUILTIN, and ZEROCONF_NONE) will periodically crash with 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 object (*.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 then 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 command 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]:   ===============================================================
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_Reporting
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]:   ===============================================================
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-minted 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 offer.  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 shortcut 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 spawned only when doing file operations, and I am not sure how to trace that.