Bug 9153 - smbd crashed with SIGABRT in rep_strlcpy()/null pointer in connections_fetch_entry
smbd crashed with SIGABRT in rep_strlcpy()/null pointer in connections_fetch_...
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: DCE-RPCs and pipes
3.6.6
All Linux
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
https://bugs.launchpad.net/ubuntu/+so...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-11 07:36 UTC by James Page
Modified: 2012-10-16 21:05 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Page 2012-09-11 07:36:22 UTC
We have had > 30 reports of this crash in Ubuntu 12.04 (Samba 3.6.3).

Still trying to identify what causes the name pointer to be NULL.

Stack trace attached.

Ubuntu bug reference: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/913809
Comment 1 James Page 2012-09-11 07:38:33 UTC
Also seen with Samba 3.6.6 from Ubuntu quantal - updating version
Comment 2 Volker Lendecke 2012-09-11 08:01:26 UTC
Can you please upload all patches that you applied on top of 3.6.3? The stacktrace does not reflect upstream code. smbd/reply.c:5110 is not a call to close_cnum, as the stacktrace indicates, it is a return statement.

Thanks,

Volker
Comment 3 James Page 2012-09-11 08:27:28 UTC
Volker

The stack trace was actually from 3.6.1 - but we see the same issue right through to 3.6.6.

smbd/reply.c:5110 (in 3.6.1):
    close_cnum(conn,req->vuid);

Apologies for the confusion.
Comment 4 Volker Lendecke 2012-09-11 15:30:20 UTC
Stared at code for a couple of hours now, but I do not have a clue how we can end up in that state. In frame 11, it would be interesting to see conn->params and conn->params->service. Then it would be interesting to see the value of the variables iNumService and ServicePtrs. If conn->params->service is >=0 and <iNumService, *ServicePtrs[conn->params->service] would also be very interesting.

Alternatively, do you have a way to reproduce this issue?
Comment 5 James Page 2012-09-11 15:34:59 UTC
I'm unable to reproduce this issue either ATM; I've requested further information from the reporters of this problem to see if we can get enough detail to create a test case.
Comment 6 Herb Lewis 2012-10-16 21:05:59 UTC
I have 3 corefiles from 3.6.0 showing this same problem. In each one they had
deleted a share sometime earlier. In all 3 cases conn->params->service was 0.
I looked at all the ServicePtrs entries and *ServicePtrs[0] contained all zeros
while the others were valid for the remaining shares defined in smb.conf. It
is interesting to note also in all 3 cases conn->connectpath was NOT the path
of the deleted share. Unfortunately the logs were only set to debug level 0
and I have not been able to reproduce this problem.