- **status**: open-confirmed --> closed-later
- **Comment**:

Confirmed, but now added to KNOWN_BUGS (as bug 89 in there) and will be closed as "later" here. We've not been able to deal with it until now and there's no work in sight. We of course appreciate anyone working on this and will re-open the minute someone wants to.

---
** [bugs:#1411] Disabling pipelining on multi handle with in-progress pipelined requests leads to heap corruption and crash**
**Status:** closed-later
**Labels:** pipelining 
**Created:** Thu Aug 14, 2014 03:38 AM UTC by Monty Brandenberg
**Last Updated:** Tue Dec 09, 2014 12:02 AM UTC
**Owner:** Linus Nielsen
With 7.38.0 closing, I thought I'd get this report in now such as it is.
This is 7.37.0 on Win7/64-bit in a large application.  A multi-handle is being used with a per-host connection limit of 8.  Multi-handle may have up to 100 HTTP GET requests queued or in-progress.  Pipelining is a dynamic setting in the application and can be toggled on and off at will.  Dynamic change is implemented by communicating the change to the thread associated with the multi-handle which then enables or disables pipelining on the multi handle, no cross-thread issue should be involved.
Observed:  with requests active on the multi handle, a transition from pipelining to non-pipelining is frequently followed by a sequence of errors.  First will be an error from the library about missing server status (thought the error code was 9, not certain).  That's followed shortly by a hard crash:  typically calloc() throwing a runtime exception.
Suspected the library fails to honor in-progress/queued requests once pipelining is turned off so I did an application mod.  When settings are changed, the multi handle is allowed to run until no requests are active then the multi options are set (enabling/disabling pipelining, etc.).  This mod appears stable and reliable.
I imagine there's an easy fix which would simply be to continue processing the side request queues regardless of pipelining setting.  Haven't checked that this is, in fact, the needed fix.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.