Bug 4821 - User Manager for Domains - Stacktrace bug
Summary: User Manager for Domains - Stacktrace bug
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Andrew Bartlett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-26 13:19 UTC by Matthias Dieter Wallnöfer
Modified: 2007-07-30 04:08 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Dieter Wallnöfer 2007-07-26 13:19:28 UTC 
After playing a bit around with the User Manager, I got a message "RPC service isn't available" on the client and a stacktrace on the server (registered with valgrind):

==1338== Invalid read of size 4
==1338==    at 0x88CCAE3: talloc_chunk_from_ptr (talloc.c:123)
==1338==    by 0x88CD850: talloc_get_name (talloc.c:618)
==1338==    by 0x88CD8D4: talloc_check_name (talloc.c:637)
==1338==    by 0x8271054: pipe_state_find (vfs_ipc.c:66)
==1338==    by 0x82710C6: pipe_state_find_key (vfs_ipc.c:82)
==1338==    by 0x82722C4: ipc_dcerpc_cmd (vfs_ipc.c:732)
==1338==    by 0x827264E: ipc_trans (vfs_ipc.c:817)
==1338==    by 0x82610D6: ntvfs_trans (ntvfs_interface.c:270)
==1338==    by 0x825F226: reply_trans_complete (trans2.c:1183)
==1338==    by 0x825F6CE: reply_trans_generic (trans2.c:1258)
==1338==    by 0x825FBD4: smbsrv_reply_trans (trans2.c:1382)
==1338==    by 0x824A221: switch_message (receive.c:567)
==1338==  Address 0x4F1AF30 is 32 bytes inside a block of size 76 free'd
==1338==    at 0x401CFCF: free (vg_replace_malloc.c:235)
==1338==    by 0x88CD661: _talloc_free (talloc.c:413)
==1338==    by 0x88CDB0F: talloc_free (talloc.c:749)
==1338==    by 0x8271E1D: ipc_close (vfs_ipc.c:524)
==1338==    by 0x826106F: ntvfs_close (ntvfs_interface.c:260)
==1338==    by 0x82526B0: smbsrv_reply_close (reply.c:1121)
==1338==    by 0x824A221: switch_message (receive.c:567)
==1338==    by 0x8249D7E: smbsrv_recv_smb_request (receive.c:159)
==1338==    by 0x87AA3C5: packet_recv (packet.c:381)
==1338==    by 0x80CD910: smbsrv_recv (smb_server.c:95)
==1338==    by 0x80DB939: stream_io_handler (service_stream.c:90)
==1338==    by 0x80DB9A9: stream_io_handler_fde (service_stream.c:104)
==1338== 
==1338== Invalid read of size 4
==1338==    at 0x88CCAFB: talloc_chunk_from_ptr (talloc.c:124)
==1338==    by 0x88CD850: talloc_get_name (talloc.c:618)
==1338==    by 0x88CD8D4: talloc_check_name (talloc.c:637)
==1338==    by 0x8271054: pipe_state_find (vfs_ipc.c:66)
==1338==    by 0x82710C6: pipe_state_find_key (vfs_ipc.c:82)
==1338==    by 0x82722C4: ipc_dcerpc_cmd (vfs_ipc.c:732)
==1338==    by 0x827264E: ipc_trans (vfs_ipc.c:817)
==1338==    by 0x82610D6: ntvfs_trans (ntvfs_interface.c:270)
==1338==    by 0x825F226: reply_trans_complete (trans2.c:1183)
==1338==    by 0x825F6CE: reply_trans_generic (trans2.c:1258)
==1338==    by 0x825FBD4: smbsrv_reply_trans (trans2.c:1382)
==1338==    by 0x824A221: switch_message (receive.c:567)
==1338==  Address 0x4F1AF30 is 32 bytes inside a block of size 76 free'd
==1338==    at 0x401CFCF: free (vg_replace_malloc.c:235)
==1338==    by 0x88CD661: _talloc_free (talloc.c:413)
==1338==    by 0x88CDB0F: talloc_free (talloc.c:749)
==1338==    by 0x8271E1D: ipc_close (vfs_ipc.c:524)
==1338==    by 0x826106F: ntvfs_close (ntvfs_interface.c:260)
==1338==    by 0x82526B0: smbsrv_reply_close (reply.c:1121)
==1338==    by 0x824A221: switch_message (receive.c:567)
==1338==    by 0x8249D7E: smbsrv_recv_smb_request (receive.c:159)
==1338==    by 0x87AA3C5: packet_recv (packet.c:381)
==1338==    by 0x80CD910: smbsrv_recv (smb_server.c:95)
==1338==    by 0x80DB939: stream_io_handler (service_stream.c:90)
==1338==    by 0x80DB9A9: stream_io_handler_fde (service_stream.c:104)
Comment 1 Andrew Bartlett 2007-07-29 20:07:56 UTC 
The issue appears to be that usrmgr attempts operations on a connection that is in fact already closed.  We should gracefully fail, but instead we follow a pointer to free()ed data.

I'm waiting on tridge getting back to me with some information on how to correctly destory our handle, so we give the correct result.
Comment 2 Andrew Bartlett 2007-07-30 04:05:13 UTC 
This should be fixed by -r 24075.  Thanks for reporting it!
Comment 3 Andrew Bartlett 2007-07-30 04:08:03 UTC 
*** Bug 4820 has been marked as a duplicate of this bug. ***