Bugs item #1982210, was opened at 2008-06-02 16:35
Message generated for change (Settings changed) made by boncz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1982210&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: PF/runtime
Group: Pathfinder "stable"
Status: Open
Resolution: Works For Me
Priority: 8
Private: No
Submitted By: Wouter Alink (vzzzbx)
>Assigned to: Peter Boncz (boncz)
Summary: XQ: crash when shredding is interrupted
Initial Comment:
The following script crashes MonetDB in about 20 steps... (0.24, preJune, 28
may 2008)
QUERY='element { "test" } { for $i in 1 to 100000000 return <aap/> }'
QUERY2='pf:add-doc("/tmp/tempdoc.xml","tempdoc.xml")'
QUERY3='pf:del-doc("tempdoc.xml")'
# create a large temporary document
time echo $QUERY | mclient -lxq > /tmp/tempdoc.xml;
n=0;
while [ "$n" -ne "100" ]
do
echo "Iter $n"
# shred document
mclient -lxq -s $QUERY2 &
MAPI_PID=$!
# do not allow mclient enough time to finish shredding
sleep .01
kill $MAPI_PID
# remove document again (should fail, as it was never shredded completely)
echo $QUERY3 | mclient -lxq
n=$(($n + 1))
sleep 2
done
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-02-17 01:40
Message:
re-opened to remind us that we should consider adding a test.
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2008-12-12 00:24
Message:
If I understand correctly, killing the Mserver resulted in a SEGV?
I tried to reproduce this in various ways, killing Mserver while
shredding, but could not reproduce this.
----------------------------------------------------------------------
Comment By: Wouter Alink (vzzzbx)
Date: 2008-06-04 15:37
Message:
Logged In: YES
user_id=621590
Originator: YES
stefan, i wasn't trying it at home ;)
i just needed some document, for which it was guaranteed that the kill
signal would arrive earlier than that the shred-doc completed, and it
seemed that this one would do the trick :)
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:56
Message:
Logged In: YES
user_id=572415
Originator: NO
File Added: server.10000000.log
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:56
Message:
Logged In: YES
user_id=572415
Originator: NO
File Added: client.10000000.log
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:56
Message:
Logged In: YES
user_id=572415
Originator: NO
File Added: server.1000000.log
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:56
Message:
Logged In: YES
user_id=572415
Originator: NO
Ok, in my 8 GB Fedora 8 desktop, Mserver survives the script with
documents of 100000 & 1000000 nodes (0.58 MB & 5.8 MB),
but indeed crashes with a
*** glibc detected *** Mserver: double free or corruption (fasttop):
0x0000000001208e90 ***
after 17 Iterations with a document of 10000000 nodes (58 MB).
See attached logs for details.
Further analysis pending.
Any help, ideas, suggestions are more than welcome!
File Added: client.1000000.log
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:39
Message:
Logged In: YES
user_id=572415
Originator: NO
How does Mserver crash, i.e., is there any message, and if so, which one?
(Such info always helps analysis & debugging a lot ...)
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-06-03 18:29
Message:
Logged In: YES
user_id=572415
Originator: NO
WARNING:
DO *NOT* TRY THIS AT HOME!
Already the first query to "create a large temporary document" will make
Mserver grow to >> 20 GB !
Is indeed such a huge document required to reproduce the problem???
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1982210&group_id=56967
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
