samba crashes when uploading files

here is the log file

Hi Thomas,

Thank you for taking the time to report this bug and helping to make Ubuntu better.

There isn't really enough information here for a developer to confirm this issue is a bug, or to begin working on it, so I am marking this bug Incomplete for now.

Since it really is a crash I recommend taking a look at [1]..
That will also answer questions like which version you are on and more.

Since samba does not crash for everyone something on your installation seems to be special, so whatever changes to the config you have made are worth to mention as well.

Also what do you copy large/small files, which version is the windows client, can you trigger it with an Ubuntu samba client as well ....?
The more you can add the better, then please add them to this bug and change the status back to New.

[1]: https://help.ubuntu.com/community/ReportingBugs

Ok thanks i will do that,

Its for small and big files, randomly, if i copy paste a few times it crashed and i need to restart the smb service. i didn't change the smdb.conf, i mad the share available by the properties of the folder and enable share this folder here.

?field.comment=Ok thanks i will do that,

Its for small and big files, randomly, if i copy paste a few times it crashed and i need to restart the smb service. i didn't change the smdb.conf, i mad the share available by the properties of the folder and enable share this folder here. I found the _usr_sbin_smdb.0.crash i hope this is what were searching for.

Ubuntu: 18.04.2 LTS
GNOME 3.28.2
OS 64-bit

I also ran this command ubuntu-bug _usr_sbin_smdb.0.crash and hit the send button but then it just dissapears and im not sure where its been send to. Excuse for my linux experience is not that greate. Please let me know if i can run some other commands

Some extra info sambo: 2:4.7.6+dsfg~ubutnu-0ubuntu2.6
Crash
apport V. 2.20.9

Traceback:
https://www.screencast.com/t/WVBI1wKdEgui

Hi Thomas,
I forgot to subscribe back then and this lay for a while on the todo list of a coworker.
I now got made aware of your reply and will take a first look.

From the crash I got this:

--- stack trace ---
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
        set = {__val = {7296, 0, 0, 0, 0, 0, 0, 94365769603472, 139709768157872, 335544320, 139709772814480, 32, 94365769603572, 94365769603472, 94365769603572, 0}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1 0x00007f10b3933801 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x55d33e2d19f4, sa_sigaction = 0x55d33e2d19f4}, sa_mask = {__val = {94365769603472, 94365769603572, 0, 0, 0, 0, 0, 17179869184, 0, 17179869184, 0, 0, 13067206327954895872, 18446744073709551615, 140729233965056, 139709772814480}}, sa_flags = -1228636032, sa_restorer = 0xfffe}
        sigs = {__val = {32, 0 <repeats 15 times>}}
        __cnt = <optimized out>
        __set = <optimized out>
        __cnt = <optimized out>
        __set = <optimized out>
#2 0x00007f10b50ceca2 in dump_core () at ../source3/lib/dumpcore.c:338
        called = true
        __FUNCTION__ = "dump_core"
#3 0x00007f10b50bbb6b in smb_panic_s3 (why=<optimized out>) at ../source3/lib/util.c:838
        cmd = <optimized out>
        result = <optimized out>
        __FUNCTION__ = "smb_panic_s3"
#4 0x00007f10b71a48cf in smb_panic (why=why@entry=0x7f10b71f2d37 "internal error") at ../lib/util/fault.c:166
No locals.
#5 0x00007f10b71a4ae6 in fault_report (sig=<optimized out>) at ../lib/util/fault.c:83
        counter = 1
#6 sig_fault (sig=<optimized out>) at ../lib/util/fault.c:94
No locals.
#7 <signal handler called>
No locals.
#8 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
No locals.
#9 0x00007f10b719d4fe in push_ucs2_talloc (ctx=ctx@entry=0x0, dest=dest@entry=0x7ffe76d586a8, src=src@entry=0x0, converted_size=converted_size@entry=0x7ffe76d586a0) at ../lib/util/charset/pull_push.c:41
        src_len = <optimized out>
#10 0x00007f10b5bbd2d0 in E_md4hash (passwd=0x0, p16=p16@entry=0x7ffe76d58a70 "") at ../libcli/auth/smbencrypt.c:78
        len = 989742900
        wpwd = 0x7ffe76d58a70
        ret = <optimized out>
#11 0x00007f10b6d9686a in create_volume_objectid (conn=conn@entry=0x55d33e2cd660, objid=objid@entry=0x7ffe76d58a70 "") at ../source3/smbd/trans2.c:3377
No locals.
#12 0x00007f10b6d97503 in smbd_do_qfsinfo (xconn=0x55d33e2ba280, conn=conn@entry=0x55d33e2cd660, mem_ctx=<optimized out>, info_level=info_level@entry=1008, flags2=flags2@entry=8, max_data_bytes=max_data_bytes@entry=64, fixed_portion=0x7ffe76d58ba0, fname=0x55d33e2d2840, ppdata=0x7ffe76d58b90, ret_data_len=0x7ffe76d58b88) at ../source3/smbd/trans2.c:3806
        objid = '\000' <repeats 15 times>
        extended_info = {samba_magic = 0, samba_version = 0, samba_subversion = 0, samba_gitcommitdate = 0, samba_version_string = "\376\025\020\261\020\177\000\000\320\300߶\020\177\000\000\004\000\000\000\000\000\000\000\220\365,>"}
        pdata = <optimized out>
        end_data = 0x55d33e2e0baf ""
        data_len = 0
        len = 0
        vname = 0x7f10b50edddc ""
        snum = <optimized out>
        fstype = 0x55d33e28fee0 "NTFS"
        filename = <optimized out>
        bytes_per_sec...

And the same with source references

--- source code stack trace ---
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
  [Error: raise.c was not found in source tree]
#1 0x00007f10b3933801 in __GI_abort () at abort.c:79
  [Error: abort.c was not found in source tree]
#2 0x00007f10b50ceca2 in dump_core () at ../source3/lib/dumpcore.c:338
  333: /* Ensure we don't have a signal handler for abort. */
  334: #ifdef SIGABRT
  335: CatchSignal(SIGABRT, SIG_DFL);
  336: #endif
  337:
  338: abort();
  339:
  340: #else /* DUMP_CORE */
  341: exit(1);
  342: #endif /* DUMP_CORE */
  343: }
#3 0x00007f10b50bbb6b in smb_panic_s3 (why=<optimized out>) at ../source3/lib/util.c:838
  833: i += 2; /* skip two chars */
  834: }
  835:
  836: for (; i+1 < strhex_len && strhex[i] != 0 && strhex[i+1] != 0; i++) {
  837: p1 = strchr(hexchars, toupper((unsigned char)strhex[i]));
  838: if (p1 == NULL) {
  839: break;
  840: }
  841:
  842: i++; /* next hex digit */
  843:
#4 0x00007f10b71a48cf in smb_panic (why=why@entry=0x7f10b71f2d37 "internal error") at ../lib/util/fault.c:166
  161: Something really nasty happened - panic !
  162: **/
  163: _PUBLIC_ void smb_panic(const char *why)
  164: {
  165: if (fault_state.panic_handler) {
  166: fault_state.panic_handler(why);
  167: _exit(1);
  168: }
  169: smb_panic_default(why);
  170: }
#5 0x00007f10b71a4ae6 in fault_report (sig=<optimized out>) at ../lib/util/fault.c:83
  78: DEBUGSEP(0);
  79: DEBUG(0,("INTERNAL ERROR: Signal %d in pid %d (%s)",sig,(int)getpid(),SAMBA_VERSION_STRING));
  80: DEBUG(0,("\nPlease read the Trouble-Shooting section of the Samba HOWTO\n"));
  81: DEBUGSEP(0);
  82:
  83: smb_panic("internal error");
  84:
  85: /* smb_panic() never returns, so this is really redundant */
  86: exit(1);
  87: }
  88:
#6 sig_fault (sig=<optimized out>) at ../lib/util/fault.c:94
  89: /****************************************************************************
  90: catch serious errors
  91: ****************************************************************************/
  92: static void sig_fault(int sig)
  93: {
  94: fault_report(sig);
  95: }
  96:
  97: /*******************************************************************
  98: setup our fault handlers
  99: ********************************************************************/
#7 <signal handler called>
#8 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
  [Error: strlen.S was not found in source tree]
#9 0x00007f10b719d4fe in push_ucs2_talloc (ctx=ctx@entry=0x0, dest=dest@entry=0x7ffe76d586a8, src=src@entry=0x0, converted_size=converted_size@entry=0x7ffe76d586a0) at ../lib/util/charset/pull_push.c:41
  36: * converted.
  37: **/
  38: bool push_ucs2_talloc(TALLOC_CTX *ctx, smb_ucs2_t **dest, const char *src,
  39: size_t *converted_size)
  40: {
  41: size_t src_len = strlen(src)+1;
  42:
  43: *dest = NULL;
  44: return convert_string_talloc(ctx, CH_UNIX, CH_UTF16LE, src, src_len,
  45: (void **)dest, converted_size);
  46: }
#1...

We see a crash in __strlen_sse2 but that seems "expected" to me as we are passing `src` to it.
And at the level above src is a null pointer.

---

Lets go up the stack, here the call to push_ucs2_talloc:
(ctx=ctx@entry=0x0, dest=dest@entry=0x7ffe76d586a8, src=src@entry=0x0, converted_size=converted_size@entry=0x7ffe76d586a0)

Note that:
- src = "where to copy from"
 and
- ctx = "The talloc memory context"
are both null.

I don't know a lot about talloc, but ctx is intentionally null in this case (seen in the call).
But copying from the empty string will surely not work.

---

This call in turn comes from E_md4hash higher up in the stack.
The empty string breaking us is the variable password which could be a hint.

---

E_md4hash gets the password from stack above - it passed it cleanly.
E_md4hash (passwd=0x0, p16=p16@entry=0x7ffe76d58a70 "")

---

So looking one up is `create_volume_objectid`
This tries to get the password with the following call:
  lp_servicename(talloc_tos(), SNUM(conn))

We know it gets a NULL pointer and passes that on.

---

I see many places where the return of lp_servicename is not checked either (bad practise)?
But on others e.g. source3/printing/notify.c line 424 it is:
422 »···const char *sharename = lp_servicename(talloc_tos(), snum);
423
424 »···if (sharename)
425 »···»···notify_printer_status_byname(ev, msg_ctx, sharename, status);

This function seems to be part of the samba3 protocol itself as I find it defined:
  source3/include/proto.h
But nowhere implemented.

Here we also find that calling this "password" might be a red herring.
It seems it just uses the same E_md4hash function, but nothing indicates that:
  lp_servicename(talloc_tos(), SNUM(conn))
Would return a password.

---

Summary:
IMHO create_volume_objectid should not blindly pass things to E_md4hash.
It should check the pointer and return an error if things are wrong.
I checked the latest 4.7 branch but it is still the same.
I don't know enough about lp_servicename really make any decisions, I'd expect something like:
 unsigned char *create_volume_objectid(connection_struct *conn, unsigned char objid[16])
 {
- E_md4hash(lp_servicename(talloc_tos(), SNUM(conn)),objid);
- return objid;
+ char* pw = lp_servicename(talloc_tos();
+ if (pw) {
+ E_md4hash(lp_servicename(talloc_tos(), SNUM(conn)),objid);
+ return objid;
+ } else {
+ return NULL;
+ }
 }

Unfortunately the functions calling create_volume_objectid also do not check the return value either. And they used it there as "src" in a memcpy so it would fail very similarly with a fault.

I think we would need to report that upstream (i.e. to people who understand what "lp_servicename(talloc_tos(), SNUM(conn))" does in that context.

@Andreas what do you think about all of the above?

@Thomas - with the data I found here do you think you could file an upstream bug and report back the bug ID here for tracking the issue and resolution?

Id like to do that but i cant find a upstream bug, im not getting a window to report a bug or so, no notification in ubuntu if you mean that. I can confirm now that whenever i create a folder, hit refresh and try to rename it it always stops working and i need to restart samba service.

Hi Thomas, you can follow [1] to report a bug upstream.

[1]: https://wiki.samba.org/index.php/Bug_Reporting

will do when it crashed again :)

The correct fix I think is to have the volume ID created at connection time, and stored on the connection structure, not re-built at runtime. Then we can just fail to connect if any of the functions fail (unlikely at that point).

I've confirmed the upstream codepaths in master still don't check for errors.

An upstream bug is the right thing to do, there is enough information here for an upstream filesystem developer to recognise that this isn't ideal.

At the time this feature was added in commit a27577815201101de4ca5c8375b7f768b6127fb2 (which became 1ddcc5c06aa88638ec89bb75cc7e4d3feb74efd0) it may well be that these functions couldn't fail.

Upstream bug: https://bugzilla.samba.org/show_bug.cgi?id=14978