Bugs item #1636828, was opened at 2007-01-16 15:23
Message generated for change (Comment added) made by sjoerd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1636828&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
>Group: MonetDB4 4.16
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: Marcin Zukowski (e-r00)
>Assigned to: Peter Boncz (boncz)
>Summary: fork() behaves strangely
Initial Comment:
I have some problems with fork, for example:
$ cat y.mil:
fork(print(1));
$ Mserver y.mil
MonetDB>!ERROR: interpret: no matching MIL operator to 'ÛÛÛÛÛÛÛÛ (int)'.
But sometimes it does:
$ cat x.mil
module(unix);
module(alarm);
PROC blah() : void {
bat("blah").insert(1,1);
commit();
}
destroy("blah"); commit();
var x := new(int, int).rename("blah").persists(true);
commit();
fork(blah());
sleep(1);
bat("blah").print();
$ Mserver x.mil
#-----------------#
# h t # name
# int int # type
#-----------------#
[ 1, 1 ]
$ Mserver < x.mil
!ERROR: interpret: no matching MIL operator to 'sleep()'.
!MAYBE YOU MEAN:
! sleep(int) : void
#-----------------#
# h t # name
# int int # type
#-----------------#
Any ideas?
----------------------------------------------------------------------
>Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-02-15 16:59
Message:
Logged In: YES
user_id=43607
Originator: NO
Peter, I'm assigning this to you. I have investigated what the problem
is, but I don't have a solution. And it's your code. Please read the
below.
This report is likely related to bug 1640248: "PF: ~500 tests randomly
fail on Solaris x86".
This is also related to the recent problem in the test web where lots of
Pathfinder tests fail on various 32-bit systems with the message "!ERROR:
interpret: no matching MIL operator to 'pn-realaudio()'."
This is what is happening (in the Pathfinder case):
In pathfinder.mil (generated from pathfinder.mx) there is code
fork(pf_logmanager());
When this is executed, the CMDfork() implementation in builtin.mx calls
forkClient() and then makes a copy of the parse tree with Myycopy() for
the argument and queues that copy with QMenqueue in the queue manager.
The copy is a shallow copy: the structure of the tree is copied to a new
structure, but no copy is made of the data that the yyval structure
contained in there points to. In particular, the sval/pval values are
shared with the original. The copy does get the bit iscopy set.
After this is done it so happens that the pathfinder module continues to
be executed until the end.
Once the end of the module is reached, the parse tree for the module is
freed. This includes the original for the argument to the fork() call and
also (and this is the important bit) the buffers that the sval/pval
pointers in that original point to. In the case here, the parse tree is
very small, consisting only of a TOK_FUNCTION node with a string valued
argument with value "pf_logmanager".
Once this is done, the queued events get a chance to run. Before the call
to fork(pf_manager()) there was a call to rpcd_start() which starts the
httpd server. This server makes a copy of MIME types, among others
"audio/x-pn-realaudio". It so happens that this copy ends up in the
memory that was previously occupied by the "pf_logmanager" string. Note
that "pf_logmanager" was allocated with GDKmalloc which has an overhead
(at the start of the memory) of 8 (on 32 bit systems) bytes, and note that
when you skip 8 bytes in "audio/x-pn-realaudio" you end up at
"pn-realaudio".
The next event which is handled is the fork(pf_logmanager()) argument. By
now the yyval.val.sval buffer was GDKfree()ed and malloc()ed to contain
"pn-realaudio" and so the interpreter tries to execute the function
pn-realaudio which of course fails.
To summarize, the problem is with the memory management during fork(). We
need to make a copy of the parse tree because of the yychunking that
happens these days. We cannot (I think) set the yysons pointer in the
original parse tree to NULL since then that bit of parse tree would never
get freed. We could perhaps allocate memory for the yyval.val.sval/pval
values (if that is what the yyval structs represent), but that would incur
a lot of malloc/free costs which we may not want to pay, plus, we may not
know how large the data is that would need to be copied.
Since this also happens in the stable release I changed the Group.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1636828&group_id=56967
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
