From: James R. <jr...@re...> - 2012-02-04 05:08:07
|
Hi all, I've added pthread mutexes around the BlockStream methods and constructors, but the read() operation is still blocking on 3078. This eliminates the possibility that it's a deadlock causing the issue since it's now guaranteed that only a single thread can enter that reading code (even though GDB reporting only one thread was inside that class during the block anyway, it couldn't hurt to eliminate this possibility). I'm going to continue checking to see whether it's POSIX functionality that's determining that the read() operation should block (despite what the C++ documentation says relating to std::istream). Regards, James Rhodes. Redpoint Software http://about.me/james.rhodes On Fri, Feb 3, 2012 at 1:37 PM, James Rhodes < jr...@re...> wrote: > Hi Lucas, > > No, it's not a pipe. The file is opened in read-write binary mode. > > Initially when looking at this I first thought that it must be waiting on > data to arrive past the end of the file (ignoring the fact that on a > reliability test like this the FS shouldn't be allocating more blocks). > However, as far as I am aware, if you try to read past the end of a file > you just get less data; a blocking API in this case doesn't make sense > since there's a guarantee no more data will be read. > > Regards, James Rhodes. > Redpoint Software > > http://about.me/james.rhodes > > > > > On Fri, Feb 3, 2012 at 12:32 AM, Lucas C. Villa Real < > lu...@go...> wrote: > >> On Thu, Feb 2, 2012 at 10:53 AM, James Rhodes >> <jr...@re...> wrote: >> > This is the output from GDB when inspecting the backtrace of threads >> when it >> > locks up: >> >> [...] >> >> > Interestingly enough it appears as though this is always occuring on >> unique >> > 3078 (so it's reproducible), but I can't see why Thread 2 would be >> stopping >> > where it is (in the middle of a read operation) specifically on 3078. >> > >> > I'm going to take a closer look at the variables surrounding the read() >> > operation on Thread 2 tomorrow. In the meantime if anyone needs a code >> > reference to look at regarding the above stack traces, the source code >> is >> > at >> http://code.redpointsoftware.com.au/System/Linux/AppTools/files/af73922c8b6c0aefa80513e55655a8546f00e9e4/appfs >> . >> >> Yes, that's where I'd suggest you to put more efforts on. Out of >> curiosity, which file type are you reading from on that function? I >> assume that's not a pipe, right? >> >> > Regards, James Rhodes. >> > Redpoint Software >> > >> > http://about.me/james.rhodes >> >> Best regards, >> >> -- >> Lucas >> "If you're looking for a reason I've a reason to give: pleasure, >> little treasure" >> > > |