Hi all,
I have reduced the code to this:
In a first shell, I run the fragment:
functor
import
Connection
System
define
functor X
define
_ = System
end
Obj = {New class $
feat utils
meth init
self.utils = coucou
end
end
init}
Ticket = {Connection.offerUnlimited Obj}
{System.printInfo "Ticket is "}
{System.show Ticket}
end
This will print a ticket to the standard output. Copy it and give it as
argument in a second shell to this:
functor
import
Application
System
Connection
define
Specs = record(ticket(single char:&t type:atom))
Args = {Application.getArgs Specs}
{System.showInfo "DEBUG -- A"}
Obj1 = {Connection.take Args.ticket}
{System.showInfo "DEBUG -- B"}
{System.show Obj1.utils}
{System.showInfo "DEBUG -- C"}
end
In my case, the second Oz vm will crash with
"gentraverser.hh:1484 assertion 'array[pos].n == (OZ_Term) -1' failed"
(I used the official 1.3.2 distribution, with the DEBUG_CHECK flag enabled,
optimizations disabled, and with Raphael change in tcpTransObj.cc).
Though the code fragment do not look useful or meaningful, they result from
a reduction of some original useful and meaningful code ;)
Note that the definition of the unused "functor X" seems to be necessary to
observe the bug.
I might be able to reduce this code further, but I need a break!
Can you tell me if you can reproduce the bug with this?
Thanks,
Christophe
On Wed, Apr 9, 2008 at 10:59 AM, Christophe Taton <
[EMAIL PROTECTED]> wrote:
> 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
