could we enable libasan on the CEA builds?
Hi Patrice, I believe you handle the CEA tests that get run automatically when we submit ganesha patches for review? We've seen some crashes recently with what look like malloc arena corruption. This one, for instance: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/426925 Would it be possible to enable libasan for these builds? ASAN would help us get a good handle on what's happening there. There is a small performance penalty in using it, but it would help us collect useful info when ganesha crashes with memory issues. I think that's probably worth it for this sort of testing. If it sounds ok to you, it should be pretty simple. To do it, you just need to make sure that libasan is installed on the machine, and then pass -DSANITIZE_ADDRESS=ON to the cmake command. libasan will also need to be installed on the host where the daemon runs as well. Thanks! -- Jeff Layton <jlayton@redhat.com>
On 09/26/18 19:50, Jeff Layton wrote:
Hi Patrice,
I believe you handle the CEA tests that get run automatically when we submit ganesha patches for review? We've seen some crashes recently with what look like malloc arena corruption. This one, for instance:
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/426925
Would it be possible to enable libasan for these builds? ASAN would help us get a good handle on what's happening there. There is a small performance penalty in using it, but it would help us collect useful info when ganesha crashes with memory issues. I think that's probably worth it for this sort of testing.
If it sounds ok to you, it should be pretty simple. To do it, you just need to make sure that libasan is installed on the machine, and then pass -DSANITIZE_ADDRESS=ON to the cmake command. libasan will also need to be installed on the host where the daemon runs as well.
Thanks!
Hi Jeff, Each CEA test runs two different configurations : 1) client 9p-RDMA / ganesha FSAL-VFS 2) client NFS v4.1 / ganesha FSAL-PROXY (local knfsd export) On the first one, ganesha is already compiled and run with libasan . We configure the ganesha compilation with the "-DSANITIZE_ADDRESS=ON" flag and then we run ganesha server with the following libasan options : ASAN_OPTIONS='detect_leaks=0:detect_stack_use_after_return=1' . Regards, -- Patrice LUCAS Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S tel : +33 (0)1 69 26 47 86 e-mail : patrice.lucas@cea.fr
On Thu, 2018-09-27 at 12:10 +0200, LUCAS Patrice wrote:
On 09/26/18 19:50, Jeff Layton wrote:
Hi Patrice,
I believe you handle the CEA tests that get run automatically when we submit ganesha patches for review? We've seen some crashes recently with what look like malloc arena corruption. This one, for instance:
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/426925
Would it be possible to enable libasan for these builds? ASAN would help us get a good handle on what's happening there. There is a small performance penalty in using it, but it would help us collect useful info when ganesha crashes with memory issues. I think that's probably worth it for this sort of testing.
If it sounds ok to you, it should be pretty simple. To do it, you just need to make sure that libasan is installed on the machine, and then pass -DSANITIZE_ADDRESS=ON to the cmake command. libasan will also need to be installed on the host where the daemon runs as well.
Thanks!
Hi Jeff,
Each CEA test runs two different configurations :
1) client 9p-RDMA / ganesha FSAL-VFS
2) client NFS v4.1 / ganesha FSAL-PROXY (local knfsd export)
On the first one, ganesha is already compiled and run with libasan . We configure the ganesha compilation with the "-DSANITIZE_ADDRESS=ON" flag and then we run ganesha server with the following libasan options : ASAN_OPTIONS='detect_leaks=0:detect_stack_use_after_return=1' .
Great! Would it also be possible to turn on libasan on the FSAL-PROXY builds and tests? That was where I saw the crash yesterday. Thanks, -- Jeff Layton <jlayton@redhat.com>
On 09/27/18 12:58, Jeff Layton wrote:
On Thu, 2018-09-27 at 12:10 +0200, LUCAS Patrice wrote:
On 09/26/18 19:50, Jeff Layton wrote:
Hi Patrice,
I believe you handle the CEA tests that get run automatically when we submit ganesha patches for review? We've seen some crashes recently with what look like malloc arena corruption. This one, for instance:
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/426925
Would it be possible to enable libasan for these builds? ASAN would help us get a good handle on what's happening there. There is a small performance penalty in using it, but it would help us collect useful info when ganesha crashes with memory issues. I think that's probably worth it for this sort of testing.
If it sounds ok to you, it should be pretty simple. To do it, you just need to make sure that libasan is installed on the machine, and then pass -DSANITIZE_ADDRESS=ON to the cmake command. libasan will also need to be installed on the host where the daemon runs as well.
Thanks! Hi Jeff,
Each CEA test runs two different configurations :
1) client 9p-RDMA / ganesha FSAL-VFS
2) client NFS v4.1 / ganesha FSAL-PROXY (local knfsd export)
On the first one, ganesha is already compiled and run with libasan . We configure the ganesha compilation with the "-DSANITIZE_ADDRESS=ON" flag and then we run ganesha server with the following libasan options : ASAN_OPTIONS='detect_leaks=0:detect_stack_use_after_return=1' .
Great! Would it also be possible to turn on libasan on the FSAL-PROXY builds and tests? That was where I saw the crash yesterday.
Thanks,
Last time I tried, libasan reported errors on a basic FSAL_PROXY test one or two years ago. I simply turned off libasan on FSAL_PROXY tests. I need to find enough time to check and solve these memory management bugs in FSAL_PROXY before turning on libasan on FSAL_PROXY. Regards, -- Patrice LUCAS Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S tel : +33 (0)1 69 26 47 86 e-mail : patrice.lucas@cea.fr
participants (2)
-
Jeff Layton -
LUCAS Patrice