Hello,
As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I tried to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. Unfortunately, this bug still appears in 4cfa54c, and I rolled back again to beta 6aeaebf . Did I misunderstoog something ?
Cheers
Hi Jean-Marc,
you got it right, we fixed the bug! I've just updated the snapshot; feel free to give it a try!
Thanks, Christian
On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier jeanmarc.mercier@gmail.com wrote:
Hello,
As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I tried to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. Unfortunately, this bug still appears in 4cfa54c, and I rolled back again to beta 6aeaebf . Did I misunderstoog something ?
Cheers
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Christian,
Thx, I tested it. It seems that a regression has been introduced : my main process, running in 30sec with 4 Go in memory with BaseX7.8 6aeaebf, never ended with this latest release. Indeed, it started disk-swapping as it is consuming more than 6 Go now (the size heap of my JAVA machine).
Do you have any clue, or suggestion, that could help us finding this regression ?
Cheers,
Jean-Marc
2014-01-30 Christian Grün christian.gruen@gmail.com
Hi Jean-Marc,
you got it right, we fixed the bug! I've just updated the snapshot; feel free to give it a try!
Thanks, Christian
On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier jeanmarc.mercier@gmail.com wrote:
Hello,
As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I
tried
to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. Unfortunately, this bug still appears in 4cfa54c, and I rolled back
again to
beta 6aeaebf . Did I misunderstoog something ?
Cheers
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Christian,
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended, even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
2014-01-30 jean-marc Mercier jeanmarc.mercier@gmail.com
Hi Christian,
Thx, I tested it. It seems that a regression has been introduced : my main process, running in 30sec with 4 Go in memory with BaseX7.8 6aeaebf, never ended with this latest release. Indeed, it started disk-swapping as it is consuming more than 6 Go now (the size heap of my JAVA machine).
Do you have any clue, or suggestion, that could help us finding this regression ?
Cheers,
Jean-Marc
2014-01-30 Christian Grün christian.gruen@gmail.com
Hi Jean-Marc,
you got it right, we fixed the bug! I've just updated the snapshot; feel free to give it a try!
Thanks, Christian
On Thu, Jan 30, 2014 at 5:07 PM, jean-marc Mercier jeanmarc.mercier@gmail.com wrote:
Hello,
As bug https://github.com/BaseXdb/basex/issues/839 has been closed, I
tried
to upgrade from BaseX7.8 6aeaebf to BaseX beta_4cfa54c. Unfortunately, this bug still appears in 4cfa54c, and I rolled back
again to
beta 6aeaebf . Did I misunderstoog something ?
Cheers
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Christian,
The point is that I don't know how to provide a self-contained query.
The only strategy I could propose, to provide a self-contained query isolating the memory management problem, is really too time-consuming : I can imagine a binary-chop search, comparing the memory management of the two BaseX beta versions, over a very complex algorithm, to isolate the problem. This is probably a week work, I can't spend such a time.
Do you have a better strategy to find the problem ?
2014-01-30 Christian Grün christian.gruen@gmail.com
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended, even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
Thanks. Could you provide us with a self-contained query? Christian
If you got time, it may already be helpful if you provide us with your code base. You could also try to run BaseX with less memory assigned (e.g. 128m) and send us the stack trace, which will be triggered via the debug flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us with the output. I can't promise anything, though.
On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < jeanmarc.mercier@gmail.com> wrote:
Christian,
The point is that I don't know how to provide a self-contained query.
The only strategy I could propose, to provide a self-contained query isolating the memory management problem, is really too time-consuming : I can imagine a binary-chop search, comparing the memory management of the two BaseX beta versions, over a very complex algorithm, to isolate the problem. This is probably a week work, I can't spend such a time.
Do you have a better strategy to find the problem ?
2014-01-30 Christian Grün christian.gruen@gmail.com
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended,
even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
Thanks. Could you provide us with a self-contained query? Christian
Mmhh...ok. I will try to find it that way. I am actually trying to send you the prof:time(prof:mem)) of the main algorithm, to compare the main perf algorithm between the two betas. My first penny guess is that it could come from Leo's work, since INLINE and TAILCALL impacted the result. Could you be kind enough to point me out his January check-in ? Having a look to his check-in, if we are lucky, could help me isolate the problem.
2014-01-31 Christian Grün christian.gruen@gmail.com
If you got time, it may already be helpful if you provide us with your code base. You could also try to run BaseX with less memory assigned (e.g. 128m) and send us the stack trace, which will be triggered via the debug flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us with the output. I can't promise anything, though.
On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < jeanmarc.mercier@gmail.com> wrote:
Christian,
The point is that I don't know how to provide a self-contained query.
The only strategy I could propose, to provide a self-contained query isolating the memory management problem, is really too time-consuming : I can imagine a binary-chop search, comparing the memory management of the two BaseX beta versions, over a very complex algorithm, to isolate the problem. This is probably a week work, I can't spend such a time.
Do you have a better strategy to find the problem ?
2014-01-30 Christian Grün christian.gruen@gmail.com
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended,
even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
Thanks. Could you provide us with a self-contained query? Christian
Topic closed : the last release (31/01/14) fixed the bug. Thx all
2014-01-31 jean-marc Mercier jeanmarc.mercier@gmail.com:
Mmhh...ok. I will try to find it that way. I am actually trying to send you the prof:time(prof:mem)) of the main algorithm, to compare the main perf algorithm between the two betas. My first penny guess is that it could come from Leo's work, since INLINE and TAILCALL impacted the result. Could you be kind enough to point me out his January check-in ? Having a look to his check-in, if we are lucky, could help me isolate the problem.
2014-01-31 Christian Grün christian.gruen@gmail.com
If you got time, it may already be helpful if you provide us with your
code base. You could also try to run BaseX with less memory assigned (e.g. 128m) and send us the stack trace, which will be triggered via the debug flag (-d) as soon as RAM is exhausted, or you could run BaseX with Java profiling arguments (e.g. -Xrunhprof:cpu=sample,depth=15) and provide us with the output. I can't promise anything, though.
On Thu, Jan 30, 2014 at 9:39 PM, jean-marc Mercier < jeanmarc.mercier@gmail.com> wrote:
Christian,
The point is that I don't know how to provide a self-contained query.
The only strategy I could propose, to provide a self-contained query isolating the memory management problem, is really too time-consuming : I can imagine a binary-chop search, comparing the memory management of the two BaseX beta versions, over a very complex algorithm, to isolate the problem. This is probably a week work, I can't spend such a time.
Do you have a better strategy to find the problem ?
2014-01-30 Christian Grün christian.gruen@gmail.com
A first clue: I set INLINELIMIT = 0 TAILCALL = -1, and the process ended,
even if it is taking now some 3/4 minutes and nearly 5,5 Go memory footprint.
Thanks. Could you provide us with a self-contained query? Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
jean-marc Mercier