On Fri, Mar 14, 2014 at 10:48:15PM +0100, Aleksandar Kuktin wrote: > >On Fri, 14 Mar 2014 21:22:35 +0100 > >Richard Z <[email protected]> wrote: > > > I have meanwhile got a few more of those crashes, mine happen always > > in offline mode. It was trigered by logrotate because polipo was > > accidentally put into offline mode for logrotation > > I have been looking at the code in client.c, I think I see the problem. > > Let's start with httpClientNoticeRequest(). It gets passed the request > (whatever that is), it parses it and gets (1) the handle for the object > contained within and (2) some sort of a reference to a "connection". It > then fills the object from disk (using objectFillFromDisk()) and calls > httpServeObject() with the above connection. httpServeObject() then > proceeds to extract the request from the connection, extracts the > object from the request, fills it up from disk for the second time and > then proceeds to deallocate it, allocate a new object that it > "attaches" to the request and proceeds to call > httpClientNoticeRequest() with that request. > > So, a bit of memory gets allocated, filled with data twice and then > deallocated all the while the stack keeps on growing. > > This hypothesis is testable. If it won't inconvenience you too much > (and you still have at least one coredump around), can you please > test the following values: > > A. from the httpClientNoticeRequest() stack: > 1. request > 2. request->connection > B. from the httpServeObject() stack: > 1. connection > 2. connection->request > > If ((A1 == B2) && (B1 == A2)), then we have successfully isolated the > infinite loop for at least one of the two crashes. > > If that truly *is* the loop, then it is obvious the problem is in the > defective data structure. We would then need to study the data > structures and see where, why and how do they get deformed.
yes, the data structures would seem to be the problem. I have a little trouble with a recent update of "abrt" which delayed me a bit - it does now automatically delete the coredump as the package keys don't match. Seems that /etc/abrt/abrt-action-save-package-data.conf needs a "OpenGPGCheck = no" .. will test in the evening. I have chunkHighMark = 819200 in polipo, any chance that would create crashes like that? Richard --- Name and OpenPGP keys available from pgp key servers
pgpl2Yy2HX5C8.pgp
Description: PGP signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech
_______________________________________________ Polipo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/polipo-users
