Debugging a primitive failure
Locked
Debugging a primitive failure
 
|
I'm taking another run at making all Monticello tests load into new
environments that get thrown away in #tearDown. (This ought to strongly test the Environment code loading, as well as prevent monkeying with global state.) To that end I've added MCTestCase >> #setUp environment := Environment withName: ('{1} test environment' format: {self className}). environment import: Smalltalk globals. MCTestCase >> #tearDown environment destroy. environment := nil. self clearPackageCache. "This line already existed" Since I had the most trouble with MCPackageTest, I changed the first line of the test from "self mockPackage unload" to [MCPackageLoader installSnapshot: self mockSnapshot. self mockPackage unload] on: EnvironmentRequest do: [:e | e resume: environment]. All was well, except that the test fails. It fails because I get a primSize fail on the changes file! After this, it seems like the changes file is corrupted, in that attempts to save any changes result in a primSize error.. One other datum of possible import is that I'm asked whether I want to automatically create a pool dictionary (as in my recent mail to the list). At any rate, I've managed to do this three times in a row. Something's not right somewhere. How might I start trying to debug this? I would try save the image and offer it up for inspection, but of course I can't do that because that involves the changes file. I can't even file out a changeset, class or method. I'm going to try redo the changes I made, and prep a changeset. To be clear: I only see the failure when I run the test, and that somehow breaks the changes file. frank |
Re: Debugging a primitive failure
|
|
On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote:
> At any rate, I've managed to do this three times in a row. Something's > not right somewhere. How might I start trying to debug this? > > I would try save the image and offer it up for inspection, but of > course I can't do that because that involves the changes file. I can't > even file out a changeset, class or method. I'm going to try redo the > changes I made, and prep a changeset. To be clear: I only see the > failure when I run the test, and that somehow breaks the changes file. In a COPY of your latest trunk image, run the attached changeset. Open up a TestRunner. Run the MCPackageTest. Try debug the failure. You should see a debugger pop up complaining that primSize failed on your changes file. At least, that's what happens locally. After this, your changes file is corrupt, in that nothing touching the changes file works anymore (primSize failures). (The test _should_ fail, because you probably won't have Inbox's Monticello-fbs.582 loaded, which would let you load MC definitions into an environment. That's not the point: the breaking of the changes file is the point.) frank |
WTF.2.cs (7K)
Re: Debugging a primitive failure
|
|
On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote:
> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: > > At any rate, I've managed to do this three times in a row. Something's > > not right somewhere. How might I start trying to debug this? > > > > I would try save the image and offer it up for inspection, but of > > course I can't do that because that involves the changes file. I can't > > even file out a changeset, class or method. I'm going to try redo the > > changes I made, and prep a changeset. To be clear: I only see the > > failure when I run the test, and that somehow breaks the changes file. > > In a COPY of your latest trunk image, run the attached changeset. Open > up a TestRunner. Run the MCPackageTest. Try debug the failure. You > should see a debugger pop up complaining that primSize failed on your > changes file. At least, that's what happens locally. After this, your > changes file is corrupt, in that nothing touching the changes file > works anymore (primSize failures). > I am not seeing the failure. What is the actual size of your changes file at the time that the problem occurs? Dave > (The test _should_ fail, because you probably won't have Inbox's > Monticello-fbs.582 loaded, which would let you load MC definitions > into an environment. That's not the point: the breaking of the changes > file is the point.) > > frank |
Re: Debugging a primitive failure
|
|
On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote:
> On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >> > At any rate, I've managed to do this three times in a row. Something's >> > not right somewhere. How might I start trying to debug this? >> > >> > I would try save the image and offer it up for inspection, but of >> > course I can't do that because that involves the changes file. I can't >> > even file out a changeset, class or method. I'm going to try redo the >> > changes I made, and prep a changeset. To be clear: I only see the >> > failure when I run the test, and that somehow breaks the changes file. >> >> In a COPY of your latest trunk image, run the attached changeset. Open >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >> should see a debugger pop up complaining that primSize failed on your >> changes file. At least, that's what happens locally. After this, your >> changes file is corrupt, in that nothing touching the changes file >> works anymore (primSize failures). >> > > I am not seeing the failure. What is the actual size of your changes > file at the time that the problem occurs? 11866903 bytes. Maybe I should get another image from some independent source. frank > Dave > > > >> (The test _should_ fail, because you probably won't have Inbox's >> Monticello-fbs.582 loaded, which would let you load MC definitions >> into an environment. That's not the point: the breaking of the changes >> file is the point.) >> >> frank > > > |
Re: Debugging a primitive failure
|
|
On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote:
> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: > > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: > >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: > >> > At any rate, I've managed to do this three times in a row. Something's > >> > not right somewhere. How might I start trying to debug this? > >> > > >> > I would try save the image and offer it up for inspection, but of > >> > course I can't do that because that involves the changes file. I can't > >> > even file out a changeset, class or method. I'm going to try redo the > >> > changes I made, and prep a changeset. To be clear: I only see the > >> > failure when I run the test, and that somehow breaks the changes file. > >> > >> In a COPY of your latest trunk image, run the attached changeset. Open > >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You > >> should see a debugger pop up complaining that primSize failed on your > >> changes file. At least, that's what happens locally. After this, your > >> changes file is corrupt, in that nothing touching the changes file > >> works anymore (primSize failures). > >> > > > > I am not seeing the failure. What is the actual size of your changes > > file at the time that the problem occurs? > > 11866903 bytes. Maybe I should get another image from some independent source. > I don't know what's happening, but take a look in the debugger when it happens. It will be failing on StandardFileStream>>size and the only reason I can think that this would occur is if the file stream was closed. The changes file gets opened and closed a lot, so maybe you're seeing some kind of concurrency issue. Dave |
Re: Debugging a primitive failure
|
|
On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote:
> On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >> >> > At any rate, I've managed to do this three times in a row. Something's >> >> > not right somewhere. How might I start trying to debug this? >> >> > >> >> > I would try save the image and offer it up for inspection, but of >> >> > course I can't do that because that involves the changes file. I can't >> >> > even file out a changeset, class or method. I'm going to try redo the >> >> > changes I made, and prep a changeset. To be clear: I only see the >> >> > failure when I run the test, and that somehow breaks the changes file. >> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >> >> should see a debugger pop up complaining that primSize failed on your >> >> changes file. At least, that's what happens locally. After this, your >> >> changes file is corrupt, in that nothing touching the changes file >> >> works anymore (primSize failures). >> >> >> > >> > I am not seeing the failure. What is the actual size of your changes >> > file at the time that the problem occurs? >> >> 11866903 bytes. Maybe I should get another image from some independent source. >> > > I don't know what's happening, but take a look in the debugger when it > happens. It will be failing on StandardFileStream>>size and the only reason > I can think that this would occur is if the file stream was closed. The > changes file gets opened and closed a lot, so maybe you're seeing some > kind of concurrency issue. MultiByteFileStream >> #size is quite high on the stack trace, but I imagine that's the same deal. frank > Dave > > |
Re: Debugging a primitive failure
|
|
On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote:
> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: > > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: > >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: > >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: > >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: > >> >> > At any rate, I've managed to do this three times in a row. Something's > >> >> > not right somewhere. How might I start trying to debug this? > >> >> > > >> >> > I would try save the image and offer it up for inspection, but of > >> >> > course I can't do that because that involves the changes file. I can't > >> >> > even file out a changeset, class or method. I'm going to try redo the > >> >> > changes I made, and prep a changeset. To be clear: I only see the > >> >> > failure when I run the test, and that somehow breaks the changes file. > >> >> > >> >> In a COPY of your latest trunk image, run the attached changeset. Open > >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You > >> >> should see a debugger pop up complaining that primSize failed on your > >> >> changes file. At least, that's what happens locally. After this, your > >> >> changes file is corrupt, in that nothing touching the changes file > >> >> works anymore (primSize failures). > >> >> > >> > > >> > I am not seeing the failure. What is the actual size of your changes > >> > file at the time that the problem occurs? > >> > >> 11866903 bytes. Maybe I should get another image from some independent source. > >> > > > > I don't know what's happening, but take a look in the debugger when it > > happens. It will be failing on StandardFileStream>>size and the only reason > > I can think that this would occur is if the file stream was closed. The > > changes file gets opened and closed a lot, so maybe you're seeing some > > kind of concurrency issue. > > MultiByteFileStream >> #size is quite high on the stack trace, but I > imagine that's the same deal. > I'm trying to suggest that you inspect the file stream itself in the debugger. I expect that this will be a MultiByteFileStream on the changes file, and that if you do a "self size" on that file stream, you will see the error in primSize. Each time something is written to the changes file we do a StandardFileStream>>setToEnd to position the file point to the end of the file prior to doing the write. That's probably where the failure is happening, and the likely cause would be that the file stream is closed for some reason. Dave |
Re: Debugging a primitive failure
|
|
On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote:
> On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >> >> >> > At any rate, I've managed to do this three times in a row. Something's >> >> >> > not right somewhere. How might I start trying to debug this? >> >> >> > >> >> >> > I would try save the image and offer it up for inspection, but of >> >> >> > course I can't do that because that involves the changes file. I can't >> >> >> > even file out a changeset, class or method. I'm going to try redo the >> >> >> > changes I made, and prep a changeset. To be clear: I only see the >> >> >> > failure when I run the test, and that somehow breaks the changes file. >> >> >> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >> >> >> should see a debugger pop up complaining that primSize failed on your >> >> >> changes file. At least, that's what happens locally. After this, your >> >> >> changes file is corrupt, in that nothing touching the changes file >> >> >> works anymore (primSize failures). >> >> >> >> >> > >> >> > I am not seeing the failure. What is the actual size of your changes >> >> > file at the time that the problem occurs? >> >> >> >> 11866903 bytes. Maybe I should get another image from some independent source. >> >> >> > >> > I don't know what's happening, but take a look in the debugger when it >> > happens. It will be failing on StandardFileStream>>size and the only reason >> > I can think that this would occur is if the file stream was closed. The >> > changes file gets opened and closed a lot, so maybe you're seeing some >> > kind of concurrency issue. >> >> MultiByteFileStream >> #size is quite high on the stack trace, but I >> imagine that's the same deal. >> > > I'm trying to suggest that you inspect the file stream itself in the > debugger. I expect that this will be a MultiByteFileStream on the changes > file, and that if you do a "self size" on that file stream, you will see > the error in primSize. Yes. And yes, I do see that error when trying to evaluate 'self size'. > Each time something is written to the changes file we do a StandardFileStream>>setToEnd > to position the file point to the end of the file prior to doing the write. > That's probably where the failure is happening, and the likely cause would > be that the file stream is closed for some reason. It would be handy if I could tell, but 'self close' also fails in #primSize:. (Oh, that's probably because the image tries to log the DoIt.) I'm not doing any heavy concurrency stuff though: I'm just running a little test, that shouldn't involve Processes at all. frank > Dave |
Re: Debugging a primitive failure
|
|
On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote:
> On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote: > > On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: > >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: > >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: > >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: > >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: > >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: > >> >> >> > At any rate, I've managed to do this three times in a row. Something's > >> >> >> > not right somewhere. How might I start trying to debug this? > >> >> >> > > >> >> >> > I would try save the image and offer it up for inspection, but of > >> >> >> > course I can't do that because that involves the changes file. I can't > >> >> >> > even file out a changeset, class or method. I'm going to try redo the > >> >> >> > changes I made, and prep a changeset. To be clear: I only see the > >> >> >> > failure when I run the test, and that somehow breaks the changes file. > >> >> >> > >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open > >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You > >> >> >> should see a debugger pop up complaining that primSize failed on your > >> >> >> changes file. At least, that's what happens locally. After this, your > >> >> >> changes file is corrupt, in that nothing touching the changes file > >> >> >> works anymore (primSize failures). > >> >> >> > >> >> > > >> >> > I am not seeing the failure. What is the actual size of your changes > >> >> > file at the time that the problem occurs? > >> >> > >> >> 11866903 bytes. Maybe I should get another image from some independent source. > >> >> > >> > > >> > I don't know what's happening, but take a look in the debugger when it > >> > happens. It will be failing on StandardFileStream>>size and the only reason > >> > I can think that this would occur is if the file stream was closed. The > >> > changes file gets opened and closed a lot, so maybe you're seeing some > >> > kind of concurrency issue. > >> > >> MultiByteFileStream >> #size is quite high on the stack trace, but I > >> imagine that's the same deal. > >> > > > > I'm trying to suggest that you inspect the file stream itself in the > > debugger. I expect that this will be a MultiByteFileStream on the changes > > file, and that if you do a "self size" on that file stream, you will see > > the error in primSize. > > Yes. And yes, I do see that error when trying to evaluate 'self size'. > > > Each time something is written to the changes file we do a StandardFileStream>>setToEnd > > to position the file point to the end of the file prior to doing the write. > > That's probably where the failure is happening, and the likely cause would > > be that the file stream is closed for some reason. > > It would be handy if I could tell, but 'self close' also fails in > #primSize:. (Oh, that's probably because the image tries to log the > DoIt.) Any of the file primitives will fail if the file stream does not refer to a valid open file. Take a look at "SourceFiles last", which is the changes file. It will have a fileID instance variable that identifies the file to the VM (it is a byte array representation of a C data structure that represents the file within the VM plugin, but you are not supposed to know that ;). The fileID instance variable of a file stream should look like a byte array, and "self closed" should answer false for the file stream. If that is not the case, then you are looking at an file stream on a file that has been closed, or that is invalid for some other reason. If you look in your debugger and see a file stream that is failing the primSize primitive (or any other file system primitive), then it probably has a fileID that is nil or zeroed out, and that is usually because the file is closed. I expect that this is what you will find when you look that the file stream in your debugger. Assuming that this is the case, then all we need to do is figure out why it's closed. Dave |
Re: Debugging a primitive failure
|
|
On 6 January 2014 22:26, David T. Lewis <[hidden email]> wrote:
> On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote: >> On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote: >> > On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: >> >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: >> >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >> >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >> >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >> >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >> >> >> >> > At any rate, I've managed to do this three times in a row. Something's >> >> >> >> > not right somewhere. How might I start trying to debug this? >> >> >> >> > >> >> >> >> > I would try save the image and offer it up for inspection, but of >> >> >> >> > course I can't do that because that involves the changes file. I can't >> >> >> >> > even file out a changeset, class or method. I'm going to try redo the >> >> >> >> > changes I made, and prep a changeset. To be clear: I only see the >> >> >> >> > failure when I run the test, and that somehow breaks the changes file. >> >> >> >> >> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >> >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >> >> >> >> should see a debugger pop up complaining that primSize failed on your >> >> >> >> changes file. At least, that's what happens locally. After this, your >> >> >> >> changes file is corrupt, in that nothing touching the changes file >> >> >> >> works anymore (primSize failures). >> >> >> >> >> >> >> > >> >> >> > I am not seeing the failure. What is the actual size of your changes >> >> >> > file at the time that the problem occurs? >> >> >> >> >> >> 11866903 bytes. Maybe I should get another image from some independent source. >> >> >> >> >> > >> >> > I don't know what's happening, but take a look in the debugger when it >> >> > happens. It will be failing on StandardFileStream>>size and the only reason >> >> > I can think that this would occur is if the file stream was closed. The >> >> > changes file gets opened and closed a lot, so maybe you're seeing some >> >> > kind of concurrency issue. >> >> >> >> MultiByteFileStream >> #size is quite high on the stack trace, but I >> >> imagine that's the same deal. >> >> >> > >> > I'm trying to suggest that you inspect the file stream itself in the >> > debugger. I expect that this will be a MultiByteFileStream on the changes >> > file, and that if you do a "self size" on that file stream, you will see >> > the error in primSize. >> >> Yes. And yes, I do see that error when trying to evaluate 'self size'. >> >> > Each time something is written to the changes file we do a StandardFileStream>>setToEnd >> > to position the file point to the end of the file prior to doing the write. >> > That's probably where the failure is happening, and the likely cause would >> > be that the file stream is closed for some reason. >> >> It would be handy if I could tell, but 'self close' also fails in >> #primSize:. (Oh, that's probably because the image tries to log the >> DoIt.) > > Any of the file primitives will fail if the file stream does not refer > to a valid open file. Take a look at "SourceFiles last", which is the > changes file. It will have a fileID instance variable that identifies the > file to the VM (it is a byte array representation of a C data structure > that represents the file within the VM plugin, but you are not supposed > to know that ;). > > The fileID instance variable of a file stream should look like a byte array, > and "self closed" should answer false for the file stream. If that is > not the case, then you are looking at an file stream on a file that has > been closed, or that is invalid for some other reason. > > If you look in your debugger and see a file stream that is failing the > primSize primitive (or any other file system primitive), then it probably > has a fileID that is nil or zeroed out, and that is usually because > the file is closed. I expect that this is what you will find when you > look that the file stream in your debugger. Assuming that this is > the case, then all we need to do is figure out why it's closed. Yep, the fileID's zeroed out. So all we need to figure out is who closed it :) frank > Dave > > |
Re: Debugging a primitive failure
|
|
On 6 January 2014 22:56, Frank Shearar <[hidden email]> wrote:
> On 6 January 2014 22:26, David T. Lewis <[hidden email]> wrote: >> On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote: >>> On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote: >>> > On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: >>> >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: >>> >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >>> >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >>> >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >>> >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >>> >> >> >> > At any rate, I've managed to do this three times in a row. Something's >>> >> >> >> > not right somewhere. How might I start trying to debug this? >>> >> >> >> > >>> >> >> >> > I would try save the image and offer it up for inspection, but of >>> >> >> >> > course I can't do that because that involves the changes file. I can't >>> >> >> >> > even file out a changeset, class or method. I'm going to try redo the >>> >> >> >> > changes I made, and prep a changeset. To be clear: I only see the >>> >> >> >> > failure when I run the test, and that somehow breaks the changes file. >>> >> >> >> >>> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >>> >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >>> >> >> >> should see a debugger pop up complaining that primSize failed on your >>> >> >> >> changes file. At least, that's what happens locally. After this, your >>> >> >> >> changes file is corrupt, in that nothing touching the changes file >>> >> >> >> works anymore (primSize failures). >>> >> >> >> >>> >> >> > >>> >> >> > I am not seeing the failure. What is the actual size of your changes >>> >> >> > file at the time that the problem occurs? >>> >> >> >>> >> >> 11866903 bytes. Maybe I should get another image from some independent source. >>> >> >> >>> >> > >>> >> > I don't know what's happening, but take a look in the debugger when it >>> >> > happens. It will be failing on StandardFileStream>>size and the only reason >>> >> > I can think that this would occur is if the file stream was closed. The >>> >> > changes file gets opened and closed a lot, so maybe you're seeing some >>> >> > kind of concurrency issue. >>> >> >>> >> MultiByteFileStream >> #size is quite high on the stack trace, but I >>> >> imagine that's the same deal. >>> >> >>> > >>> > I'm trying to suggest that you inspect the file stream itself in the >>> > debugger. I expect that this will be a MultiByteFileStream on the changes >>> > file, and that if you do a "self size" on that file stream, you will see >>> > the error in primSize. >>> >>> Yes. And yes, I do see that error when trying to evaluate 'self size'. >>> >>> > Each time something is written to the changes file we do a StandardFileStream>>setToEnd >>> > to position the file point to the end of the file prior to doing the write. >>> > That's probably where the failure is happening, and the likely cause would >>> > be that the file stream is closed for some reason. >>> >>> It would be handy if I could tell, but 'self close' also fails in >>> #primSize:. (Oh, that's probably because the image tries to log the >>> DoIt.) >> >> Any of the file primitives will fail if the file stream does not refer >> to a valid open file. Take a look at "SourceFiles last", which is the >> changes file. It will have a fileID instance variable that identifies the >> file to the VM (it is a byte array representation of a C data structure >> that represents the file within the VM plugin, but you are not supposed >> to know that ;). >> >> The fileID instance variable of a file stream should look like a byte array, >> and "self closed" should answer false for the file stream. If that is >> not the case, then you are looking at an file stream on a file that has >> been closed, or that is invalid for some other reason. >> >> If you look in your debugger and see a file stream that is failing the >> primSize primitive (or any other file system primitive), then it probably >> has a fileID that is nil or zeroed out, and that is usually because >> the file is closed. I expect that this is what you will find when you >> look that the file stream in your debugger. Assuming that this is >> the case, then all we need to do is figure out why it's closed. > > Yep, the fileID's zeroed out. So all we need to figure out is who closed it :) So am I the only guy getting hit by this? I'll be working in an image, not doing anything much, and suddenly I can't save any changes: saving a method, do-it, etc. all throw up debuggers because the FileStream's closed. (I'm running Windows 8 64bit - any other such users out there?) frank > frank > >> Dave >> >> |
Re: Debugging a primitive failure
|
|
Is it possible another copy of the image launched? Two images trying
to use the same .changes file? On Fri, Jan 10, 2014 at 4:50 AM, Frank Shearar <[hidden email]> wrote: > On 6 January 2014 22:56, Frank Shearar <[hidden email]> wrote: >> On 6 January 2014 22:26, David T. Lewis <[hidden email]> wrote: >>> On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote: >>>> On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote: >>>> > On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: >>>> >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: >>>> >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >>>> >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >>>> >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >>>> >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >>>> >> >> >> > At any rate, I've managed to do this three times in a row. Something's >>>> >> >> >> > not right somewhere. How might I start trying to debug this? >>>> >> >> >> > >>>> >> >> >> > I would try save the image and offer it up for inspection, but of >>>> >> >> >> > course I can't do that because that involves the changes file. I can't >>>> >> >> >> > even file out a changeset, class or method. I'm going to try redo the >>>> >> >> >> > changes I made, and prep a changeset. To be clear: I only see the >>>> >> >> >> > failure when I run the test, and that somehow breaks the changes file. >>>> >> >> >> >>>> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >>>> >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >>>> >> >> >> should see a debugger pop up complaining that primSize failed on your >>>> >> >> >> changes file. At least, that's what happens locally. After this, your >>>> >> >> >> changes file is corrupt, in that nothing touching the changes file >>>> >> >> >> works anymore (primSize failures). >>>> >> >> >> >>>> >> >> > >>>> >> >> > I am not seeing the failure. What is the actual size of your changes >>>> >> >> > file at the time that the problem occurs? >>>> >> >> >>>> >> >> 11866903 bytes. Maybe I should get another image from some independent source. >>>> >> >> >>>> >> > >>>> >> > I don't know what's happening, but take a look in the debugger when it >>>> >> > happens. It will be failing on StandardFileStream>>size and the only reason >>>> >> > I can think that this would occur is if the file stream was closed. The >>>> >> > changes file gets opened and closed a lot, so maybe you're seeing some >>>> >> > kind of concurrency issue. >>>> >> >>>> >> MultiByteFileStream >> #size is quite high on the stack trace, but I >>>> >> imagine that's the same deal. >>>> >> >>>> > >>>> > I'm trying to suggest that you inspect the file stream itself in the >>>> > debugger. I expect that this will be a MultiByteFileStream on the changes >>>> > file, and that if you do a "self size" on that file stream, you will see >>>> > the error in primSize. >>>> >>>> Yes. And yes, I do see that error when trying to evaluate 'self size'. >>>> >>>> > Each time something is written to the changes file we do a StandardFileStream>>setToEnd >>>> > to position the file point to the end of the file prior to doing the write. >>>> > That's probably where the failure is happening, and the likely cause would >>>> > be that the file stream is closed for some reason. >>>> >>>> It would be handy if I could tell, but 'self close' also fails in >>>> #primSize:. (Oh, that's probably because the image tries to log the >>>> DoIt.) >>> >>> Any of the file primitives will fail if the file stream does not refer >>> to a valid open file. Take a look at "SourceFiles last", which is the >>> changes file. It will have a fileID instance variable that identifies the >>> file to the VM (it is a byte array representation of a C data structure >>> that represents the file within the VM plugin, but you are not supposed >>> to know that ;). >>> >>> The fileID instance variable of a file stream should look like a byte array, >>> and "self closed" should answer false for the file stream. If that is >>> not the case, then you are looking at an file stream on a file that has >>> been closed, or that is invalid for some other reason. >>> >>> If you look in your debugger and see a file stream that is failing the >>> primSize primitive (or any other file system primitive), then it probably >>> has a fileID that is nil or zeroed out, and that is usually because >>> the file is closed. I expect that this is what you will find when you >>> look that the file stream in your debugger. Assuming that this is >>> the case, then all we need to do is figure out why it's closed. >> >> Yep, the fileID's zeroed out. So all we need to figure out is who closed it :) > > So am I the only guy getting hit by this? I'll be working in an image, > not doing anything much, and suddenly I can't save any changes: saving > a method, do-it, etc. all throw up debuggers because the FileStream's > closed. (I'm running Windows 8 64bit - any other such users out > there?) > > frank > >> frank >> >>> Dave >>> >>> > |
Re: Debugging a primitive failure
|
|
On 11 January 2014 22:32, Chris Muller <[hidden email]> wrote:
> Is it possible another copy of the image launched? Two images trying > to use the same .changes file? Not in this case, no. Just one image open, mucking around. It happens constantly when hacking on Monticello-into-Environment hacking, but this last time I was just tooling around, when the debugger popped up. frank > On Fri, Jan 10, 2014 at 4:50 AM, Frank Shearar <[hidden email]> wrote: >> On 6 January 2014 22:56, Frank Shearar <[hidden email]> wrote: >>> On 6 January 2014 22:26, David T. Lewis <[hidden email]> wrote: >>>> On Mon, Jan 06, 2014 at 09:41:12PM +0000, Frank Shearar wrote: >>>>> On 6 January 2014 20:30, David T. Lewis <[hidden email]> wrote: >>>>> > On Mon, Jan 06, 2014 at 06:43:50PM +0000, Frank Shearar wrote: >>>>> >> On 6 January 2014 18:06, David T. Lewis <[hidden email]> wrote: >>>>> >> > On Mon, Jan 06, 2014 at 05:51:24PM +0000, Frank Shearar wrote: >>>>> >> >> On 6 January 2014 14:23, David T. Lewis <[hidden email]> wrote: >>>>> >> >> > On Mon, Jan 06, 2014 at 01:48:17PM +0000, Frank Shearar wrote: >>>>> >> >> >> On 6 January 2014 11:40, Frank Shearar <[hidden email]> wrote: >>>>> >> >> >> > At any rate, I've managed to do this three times in a row. Something's >>>>> >> >> >> > not right somewhere. How might I start trying to debug this? >>>>> >> >> >> > >>>>> >> >> >> > I would try save the image and offer it up for inspection, but of >>>>> >> >> >> > course I can't do that because that involves the changes file. I can't >>>>> >> >> >> > even file out a changeset, class or method. I'm going to try redo the >>>>> >> >> >> > changes I made, and prep a changeset. To be clear: I only see the >>>>> >> >> >> > failure when I run the test, and that somehow breaks the changes file. >>>>> >> >> >> >>>>> >> >> >> In a COPY of your latest trunk image, run the attached changeset. Open >>>>> >> >> >> up a TestRunner. Run the MCPackageTest. Try debug the failure. You >>>>> >> >> >> should see a debugger pop up complaining that primSize failed on your >>>>> >> >> >> changes file. At least, that's what happens locally. After this, your >>>>> >> >> >> changes file is corrupt, in that nothing touching the changes file >>>>> >> >> >> works anymore (primSize failures). >>>>> >> >> >> >>>>> >> >> > >>>>> >> >> > I am not seeing the failure. What is the actual size of your changes >>>>> >> >> > file at the time that the problem occurs? >>>>> >> >> >>>>> >> >> 11866903 bytes. Maybe I should get another image from some independent source. >>>>> >> >> >>>>> >> > >>>>> >> > I don't know what's happening, but take a look in the debugger when it >>>>> >> > happens. It will be failing on StandardFileStream>>size and the only reason >>>>> >> > I can think that this would occur is if the file stream was closed. The >>>>> >> > changes file gets opened and closed a lot, so maybe you're seeing some >>>>> >> > kind of concurrency issue. >>>>> >> >>>>> >> MultiByteFileStream >> #size is quite high on the stack trace, but I >>>>> >> imagine that's the same deal. >>>>> >> >>>>> > >>>>> > I'm trying to suggest that you inspect the file stream itself in the >>>>> > debugger. I expect that this will be a MultiByteFileStream on the changes >>>>> > file, and that if you do a "self size" on that file stream, you will see >>>>> > the error in primSize. >>>>> >>>>> Yes. And yes, I do see that error when trying to evaluate 'self size'. >>>>> >>>>> > Each time something is written to the changes file we do a StandardFileStream>>setToEnd >>>>> > to position the file point to the end of the file prior to doing the write. >>>>> > That's probably where the failure is happening, and the likely cause would >>>>> > be that the file stream is closed for some reason. >>>>> >>>>> It would be handy if I could tell, but 'self close' also fails in >>>>> #primSize:. (Oh, that's probably because the image tries to log the >>>>> DoIt.) >>>> >>>> Any of the file primitives will fail if the file stream does not refer >>>> to a valid open file. Take a look at "SourceFiles last", which is the >>>> changes file. It will have a fileID instance variable that identifies the >>>> file to the VM (it is a byte array representation of a C data structure >>>> that represents the file within the VM plugin, but you are not supposed >>>> to know that ;). >>>> >>>> The fileID instance variable of a file stream should look like a byte array, >>>> and "self closed" should answer false for the file stream. If that is >>>> not the case, then you are looking at an file stream on a file that has >>>> been closed, or that is invalid for some other reason. >>>> >>>> If you look in your debugger and see a file stream that is failing the >>>> primSize primitive (or any other file system primitive), then it probably >>>> has a fileID that is nil or zeroed out, and that is usually because >>>> the file is closed. I expect that this is what you will find when you >>>> look that the file stream in your debugger. Assuming that this is >>>> the case, then all we need to do is figure out why it's closed. >>> >>> Yep, the fileID's zeroed out. So all we need to figure out is who closed it :) >> >> So am I the only guy getting hit by this? I'll be working in an image, >> not doing anything much, and suddenly I can't save any changes: saving >> a method, do-it, etc. all throw up debuggers because the FileStream's >> closed. (I'm running Windows 8 64bit - any other such users out >> there?) >> >> frank >> >>> frank >>> >>>> Dave >>>> >>>> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |