Hi Raphael,
I changed the assertion in the way you describe. This effectively removed
the assertion failure on the first host, but not on the second host which
now systematically fails with :
gentraverser.hh:1484 assertion 'array[pos].n == (OZ_Term) -1' failed
At this point, the vm stack looks:
#0 OZ_error (format=0x8168b33 "%s:%d assertion '%s' failed") at base.cc:72
#1 0x0812556e in BuilderRefTable::set (this=0x8274040, val=3081482144,
pos=1) at gentraverser.hh:1484
#2 0x081255f2 in Builder::setTerm (this=0x827ba80, t=3081482144, i=1) at
gentraverser.hh:1598
#3 0x081266b2 in Builder::buildValueRef (this=0x827ba80, n=1) at
gentraverser.hh:2036
#4 0xb7b52e60 in dpUnmarshalTerm (bs=0x8273ca0, b=0x827ba80) at
dpMarshaler.cc:1930
#5 0xb7b8ddda in MsgContainer::unmarshal (this=0x826af00, bb=0x8273ca0,
transController=0x824ba48) at msgContainer_marshal.m4cc:292
#6 0xb7b99080 in TCPTransObj::unmarshal (this=0x8273d20) at
tcpTransObj.cc:306
#7 0xb7b98949 in TCPTransObj::readHandler (this=0x8273d20, fd=7) at
tcpTransObj.cc:388
#8 0xb7b989a4 in tcpTransObj_readHandler (fd=7, o=0x8273d20) at
tcpTransObj.cc:56
#9 0x080c0cc7 in oz_io_handle () at ioHandler.cc:216
#10 0x080c280d in AM::checkStatus (this=0x8174e20, block=0) at am.cc:635
#11 0x080c2954 in AM::suspendEngine (this=0x8174e20) at am.cc:528
#12 0x080daaeb in scheduler () at scheduler.cc:88
#13 0x08131a31 in OZ_main (argc=3, argv=0xbfa6dea4) at foreign.cc:2162
#14 0x0812f6ee in main (argc=Cannot access memory at address 0xffffffff
Actually, the corresponding failing Oz operation is the "transmission" of an
instantiated Oz module from the first host to the second host. I'm still
working on the extraction of a minimal Oz code that would reproduce this.
cheers,
Christophe
On Wed, Apr 9, 2008 at 9:51 AM, Raphael Collet <[EMAIL PROTECTED]>
wrote:
> Dear Christophe,
>
> I had a look at the file tcpTransObj.cc. I found out that the assertion
> is incorrect. Change the assertion as follows, and give it a try.
>
> Assert(writeBuffer->availableSpace()>=0);
>
> The assertion looks wrong, but in fact it is correct this way, due to a
> (stupid) feature of the buffer.
>
> Can you tell us the result? I am not sure it will solve the problem, but
> it's worth a try...
>
>
> Cheers,
> raph
>
> Christophe Taton wrote:
>
> > Amendment to my last message:
> >
> > When I run my project on two nodes, I observe two kinds of failure:
> > - either: "tcpTransObj.cc:192 assertion
> > 'writeBuffer->availableSpace()>=1' failed" on the first node,
> > - or: "gentraverser.hh:1484 assertion 'array[pos].n == (OZ_Term) -1'
> > failed" on the second node.
> >
> > Any idea? Does it make sense for me to look more deeply into this?
> > Thanks,
> >
> > Christophe
> >
> > On Tue, Apr 8, 2008 at 11:05 PM, Christophe Taton <
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > wrote:
> >
> > Trying to find out what was going on, I rebuilt the vm with some
> > debugging flags. Rerunning my project under this vm always results
> > in the following assertion failure:
> > tcpTransObj.cc:192 assertion 'writeBuffer->availableSpace()>=1'
> > failed
> >
> >
> > On Mon, Apr 7, 2008 at 10:33 AM, Christophe Taton
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > wrote:
> >
> > Hi all,
> >
> > I am experiencing a bug when running one of my projects in a
> > distributed environment, leading to a systematic crash of one of
> > the virtual machines (either a segfault or a "glibc: double free
> > or corruption..."). Unfortunately I have not yet been able to
> > isolate the origin of the bug.
> >
> > I wondered whether there is a documentation on how to debug the
> > oz VM itself?
> >
> > Thanks in advance for you help,
> > Christophe Taton
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > _________________________________________________________________________________
> > mozart-users mailing list
> > [email protected]
> > http://www.mozart-oz.org/mailman/listinfo/mozart-users
> >
>
>
> _________________________________________________________________________________
> mozart-users mailing list
> [email protected]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
>
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
