Bug 5208 - random memory corruption on hpux
random memory corruption on hpux
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.28
All HP-UX
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-17 01:15 UTC by David Leonard (550 5.7.1 Unable to deliver)
Modified: 2008-01-17 10:21 UTC (History)
0 users

See Also:


Attachments
fix uninitialized vars in vfs_hpuxacl.c (594 bytes, patch)
2008-01-17 01:18 UTC, David Leonard (550 5.7.1 Unable to deliver)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Leonard (550 5.7.1 Unable to deliver) 2008-01-17 01:15:19 UTC
When a new file is being written to a share on HP-UX, I was getting either 'double free' errors, or NT_STATUS_INVALID_HANDLE errors. I tracked this down to some uninitialized pointers in the HPUX ACL module.
Comment 1 David Leonard (550 5.7.1 Unable to deliver) 2008-01-17 01:18:18 UTC
Created attachment 3106 [details]
fix uninitialized vars in vfs_hpuxacl.c

attached patch appears to fix it for me.

While hunting down this bug, I also spotted this, which should be considered:
--- source/smbd/open.c  (revision 281)
+++ source/smbd/open.c  (working copy)
@@ -1200,6 +1200,7 @@
                } else {
                        del_deferred_open_entry(lck, mid);
                        TALLOC_FREE(lck);
+                       lck = NULL;
                }

                /* Ensure we don't reprocess this message. */
Comment 2 Volker Lendecke 2008-01-17 08:42:57 UTC
That's very unlikely to fix it. TALLOC_FREE alreay NULLs out the pointer. I don't have a solution though.

Sorry,

Volker
Comment 3 David Leonard (550 5.7.1 Unable to deliver) 2008-01-17 09:57:51 UTC
yeah, you're right. TALLOC_FREE() nulls the pointer. so that inline patch is bogus.

However, the patch inside the attachment is different, and works.
Comment 4 Volker Lendecke 2008-01-17 10:21:51 UTC
Ah, ok. I did not look at the patch as your comment already include some patch-like lines :-)

Pushed with 0cbc43562e358e30ba5d431ca54c42bb2d09dc44 and a3b36c3cb0fe5f3e78c200290afa59829934f496.

Thanks,

Volker