[07:09:30] *** fogbank has joined #JNode.org
[18:54:02] *** loic has joined #JNode.org
[18:57:24] <loic> hi
[18:58:07] *** FabienD has joined #JNode.org
[19:03:56] <loic> FabienD: hi
[19:20:57] <FabienD> hi loic and others
[19:21:08] <FabienD> still no news from Daeken
[19:21:20] <FabienD> afaik he never sent a message
[19:21:37] * FabienD having dinner
[19:26:18] <peda_> hi all
[20:09:48] <FabienD> peda_: I have been told that git has not been designed to transport svn informations
[20:10:37] <peda_> what informations do you mean?
[20:11:13] <FabienD> that mean that's not possible to create an svn mirror, push the result to remote git repo, then pull the repo from the remote server and still have the svn informations for the sync
[20:11:51] <FabienD> from my understanding, the first push to remote repo doesn't transport the svn informations needed for mirroring
[20:12:17] <peda_> hmm I do not see/understand the problem
[20:12:39] <peda_> actually I'm locally using git and I used it to checkout svn and to commit to svn
[20:12:40] <FabienD> I did the above scenario and had to do again the 3 hours sync with svn
[20:16:07] <FabienD> but if you start from a new local repo, you have to do the 3 hours creation from svn, right ?
[20:17:18] <peda_> ah
[20:17:25] <FabienD> it seems the remote-svn entry + some other svn datas in the local git repo is not sent to the remote repo
[20:17:26] <peda_> ok I think I got what you mean :)
[20:17:36] <peda_> you can set these informations afterwards too
[20:17:50] <peda_> though don't ask me how
[20:18:35] <FabienD> I won't ask 'how' but "where did you see that ?" :)
[20:18:54] <peda_> :)
[20:18:54] <FabienD> sorry, forget the question
[20:19:19] <FabienD> I did the set (with help from the #git channel)
[20:19:26] <peda_> ok
[20:20:05] <FabienD> but it's scanning all svn revisions so it's maybe almost as long as from a clean git repo
[20:20:23] <FabienD> so I stopped the process when I saw what's happening
[20:26:07] <peda_> I'm sure you can also set what revision was checkedout last
[20:26:14] <peda_> you just need to know how :)
[21:16:54] <loic> peda_: there's something i don't understand
[21:18:01] <loic> i my GenHeapManager, in the start method, i execute a start of GenGCSweepThread and there is a real panic
[21:18:51] <loic> The first thing i do in the run method is an Unsafe.debug() (i known this method is not thread safe, but there's also the panic without the debug statements)
[21:19:10] <loic> here is my code http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/generational/GenHeapManager.java#line188
[21:19:21] <loic> and http://gitorious.org/+jnode-new-gc-algo-developers/jnode/new-gc-algorithms/blobs/master/core/src/core/org/jnode/vm/memmgr/generational/GenGCSweepThread.java#line80
[21:19:53] <loic> if i comment the gcSweepThread.start() , jnode boots well
[21:19:56] <loic> any ideas?
[21:22:53] <peda_> so the startMonitor.enter() in SweepThread never gets executed?
[21:23:14] <peda_> and btw, Unsafe.debug should be thread safe
[21:23:24] <peda_> it has its own lowlevel asm lock
[21:25:39] <peda_> oh and btw, there is quite a bit information in the register dump of a real panic
[21:26:16] <peda_> you just need to be able to read it.. I forgot most of it but I think I could work out most of it again (though we should document it that time :))
[21:51:19] <loic> http://ups.imagup.com/07/1264759685.png
[21:51:46] <loic> peda_: you will find my dum above
[21:52:37] <loic> "GenHeapManager.start(start threads)" debug message is the last instruction before the gcSweepThread.start()
[22:04:11] <peda_> what I found is: http://en.wikipedia.org/wiki/Interrupt_descriptor_table
[22:04:26] <peda_> it compares to the "int" value in the register dump
[22:04:31] <peda_> so you have a page fault
[22:04:51] <peda_> CR2 contains the last address that was going to be accessed
[22:13:21] <peda_> I'm not quite sure, but one possible bug is in GenHeapManager:
[22:13:47] <peda_> the gcManager,gcThread,gcSweepThread should be instantiated in start() and not in the constructor!
[22:14:38] <peda_> The reason: the constructor gets called during build tome, so they do not get registered as real threads, but if you do it in start() you have created them during runtime
[22:15:38] <peda_> as you see in the current HeapManager the do stuff like "new VmDefaultHeap()", though you have to watch carefully as it gets initialized during runtime! (Even though it's created during build time)
[22:31:38] <loic> ok, thanks :)
[22:48:59] <peda_> did that help, does it work now?
[22:49:37] <loic> i had worked
[22:49:46] <loic> not now (i break it again)
[22:50:06] <loic> but it's normal, i'm uncommenting futher code
[22:50:08] <loic> :)
[22:50:19] <peda_> :)
[22:50:50] *** ismael has joined #JNode.org
[23:38:58] <FabienD> peda_: do you know "git-stash" command ?
[23:39:14] <peda_> yes
[23:39:29] <peda_> but I didn't use it yet

   January 28, 2010  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >