A bug in introduced 13th of january have a code path wich end in referencing a null pointer. I expect the following info is precise enough, as it pinpoint the problematic place, but otherwise let me know. The problem came with commit 88ce2c71e36b0e556dfbd74f6c8c4de7034b2075 and the related commits, which is part of release 3.4.11 and 3.4.12 Check the queue pointer (the NULL argument in the first call) in the following call chain: source3/libsmb/async_smb.c: struct tevent_req *cli_session_request_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, int sock, const struct nmb_name *called, const struct nmb_name *calling) { ... subreq = writev_send(state, ev, NULL, sock, state->iov, 3); lib/async_req/async_sock.c: struct tevent_req *writev_send(TALLOC_CTX *mem_ctx, struct tevent_context *ev, struct tevent_queue *queue, int fd, struct iovec *iov, int count) { ... if (!tevent_queue_add(queue, ev, result, writev_trigger, NULL)) { lib/tevent/tevent_queue.c: bool tevent_queue_add(struct tevent_queue *queue, struct tevent_context *ev, struct tevent_req *req, tevent_queue_trigger_fn_t trigger, void *private_data) { ... DLIST_ADD_END(queue->list, e, struct tevent_queue_entry *);
Created attachment 6407 [details] Patch gna, 1a69ba894514dd4e is missing in 3.4 unfortunately. Can you try the attached patch? Thanks, Volker
(In reply to comment #1) > Can you try the attached patch? As much as I like to help, I am afraid, I can not. The setup is in production environment and I updated to 3.4.12 basically to fix some other problems and thought it made sense to use newest stable. After looking at the code and seen the amount of code added for 3.4.11 to fix a problem not affecting my company and people depend on the winbind to work, it was decided to go for the safer choice of 3.4.10 + security patch from 3.4.12 I do not have a test environment to test it and I do not know how to tricker the problem. Anyway, thank you for the fast response. I hope you have some other mean of testing. Best regards, Jesper
Ok, compiled 3.4.12 plain. Crashes as you describe. Applied the patch. Does not crash anymore.
The reproducer is to run against a DC that only listens on 139.
Comment on attachment 6407 [details] Patch Good backport of code already in 3.5.x. Jeremy.
Re-assigning to Karolin for inclusion in 3.4.next. Jeremy.
Pushed to v3-4-test. Will be included in the next release. Closing out bug report. Thanks!