[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY
From: |
Michael Kaufman |
Subject: |
Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY |
Date: |
Mon, 16 Oct 2017 09:13:13 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
With the block placed at line 336, this line does _not_ appear in the
output (and it still trips).
And yes, I made sure that I did get this changed version compiled and
linked.
M
PS: In my code, I replaced the default error handler with this:
static void msadams_error_handler(const char *reason, const char *file,
int line, int gsl_errno)
{
bool doabort = true;
if (gsl_errno == GSL_ESANITY) doabort = false;
fprintf(stderr, "GSL error [%d] %s:%d : %s\n", gsl_errno, file, line,
reason);
if (doabort) abort();
}
If I don't replace the default error handler, the program aborts with
GSL_ESANITY just as before, even with your change to
msadams_failurehandler().
On 10/15/17 4:51 AM, Tuomo Keskitalo wrote:
Hi,
can you please test add this following snippet of code to end of
function msadams_failurehandler(), just before "return GSL_SUCCESS;" and
try behavior again, thanks! You should see that line printed in output.
Does it still crash? PS. I created bug report, this is [bug #52230].
if ((int)state->ordprev - (int)ord >= 2)
{
printf("TKDEBUG: MSADAMS ORDER CHANGE: ord %d ordprev %d\n",
(int)ord, (int)state->ordprev);
msadams_reset (vstate, dim);
}
On 09.10.2017 15:52, Michael Kaufman wrote:
Thanks! Looks like the solver hits a bump while accelerating on a
high gear. That should not be a problem, though. I'll take a look at
the code, but it will take time.
Meanwhile, if you have time, you can add "#define DEBUG" in the
beginning of msadams.c and recompile GSL. This should make msadams
print out _lots_ of debug info and data, that would help decipher
this issue. Interesting stuff happens between t=5116.13 and t=5116.27.
Yeah, wasn't quite expecting a 1 GB output file. Attached is a
truncated section that has the steps in question. I've prefixed
"PROGRAM" to the output lines that are not coming out of msadams.c
M
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, (continued)
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/02
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/02
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/03
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/05
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/05
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/05
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/05
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/08
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/09
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/15
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY,
Michael Kaufman <=
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/16
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Michael Kaufman, 2017/10/16
- Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY, Tuomo Keskitalo, 2017/10/17