Sun 21 Feb 2010 08:04:00 PM UTC, comment #7:
Thank you. In the remaining cases it's necessary to call the _set functions before _iterate, to provide the inital starting values. I believe those test cases will pass once that is done.
|
Sat 20 Feb 2010 08:04:42 PM UTC, comment #6:
Hello,
I've modified all *x to be x[] in the tests and almost all tests passed, except 4 tests. An expert needed to decide if there's a misuse here. Tests cases are in the new attachment.
|
Fri 19 Feb 2010 03:48:16 PM UTC, comment #5:
I'm closing this ticket as there are too many false positives for me to check. Please let us know when the Autotest tool has support for distinguishing *x and x[] - it does look like it would be useful then.
|
Mon 15 Feb 2010 12:58:54 PM UTC, comment #4:
It doesn't handle this yet. But I have some plans on the future for resolving this ambiguity. If you suppose test case to be incorrect, you can skip it and investigate others.
|
Mon 15 Feb 2010 11:38:00 AM UTC, comment #3:
The SEGVs seem to be due to the ambiguity between pointer arguments and arrays. For example in the following code f_in and f_out should be arrays of length 256 (the first argument "n" of the gsl_dht_new(n,nu,xmax) call). How does your tool handle this?
gsl_dht.h, libgsl.so.0.14.0
[] gsl_dht_apply (gsl_dht const* t, double* f_in, double* f_out)
#include <stdlib.h>
#include <gsl_dht.h>
int main(int argc, char *argv[])
{
gsl_dht* t = gsl_dht_new(256, 1.5, 2.5);
double f_in = 3.5;
double f_out = 4.5;
gsl_dht_apply(t, &f_in, &f_out); //target call
return 0;
}
|
Sun 14 Feb 2010 10:19:24 PM UTC, comment #2:
Yes, it is more correctly to consider all aborts in the report as something like warnings. But what's about segfaults?
|
Sun 14 Feb 2010 09:43:56 PM UTC, comment #1:
From looking at your results for areas of GSL I know, it seems like some if not the majority of the ABRT "failures" are problems being correctly detected and handled using the GSL error infrastructure.
You may want to consider ABRT to be non-failure and/or to replace the default error handler using something like gsl_set_error_handler or gsl_set_error_handler_off.
On perfect example is from the "failing" gsl_bspline_eval test case:
#include <stdlib.h>
#include <gsl_bspline.h>
int main(int argc, char *argv[])
{
gsl_vector* B = gsl_vector_alloc(1);
gsl_bspline_workspace* w = gsl_bspline_alloc(2, 3);
gsl_bspline_eval(1.5, B, w); //target call
return 0;
}
gsl: bspline.c:394: ERROR: vector B not of length n
Default GSL error handler invoked.
This code is 100% working as designed.
|
Sun 14 Feb 2010 08:15:53 PM UTC, original submission:
Hello,
I have performed some sanity checks for the library API and have found that
it is not 100% safe. I have used API-Sanity-Autotest tool and have detected
segfaults in the 124/4045 functions (3%). Test results are in the
attachment. See "Received signal SEGV" section of the report.
Environment: Mandriva 2009.1, KDE-4.2, gcc-4.3.2, x86, gsl-1.13
|