William Allen Simpson wrote on Mon, Jun 22, 2015 at 03:26:38PM -0400:
> Moreover, requiring library changes adds more variability to
> the mix. The only patch that matters (to me) is the final patch.
I'd agree if we squash them after review, but since we don't, anyone
bisecting do care about all
>From Malahal :
Malahal has uploaded a new change for review.
https://review.gerrithub.io/237283
Change subject: Suppress spurious valgrind report about lock->lock_reclaim.
..
Suppress spurious valgrind report about lock->loc
>From Malahal :
Malahal has uploaded a new change for review.
https://review.gerrithub.io/237285
Change subject: Teach valgrind about GPFS fsal ioctls.
..
Teach valgrind about GPFS fsal ioctls.
Instead of putting code here a
>From Malahal :
Malahal has uploaded a new change for review.
https://review.gerrithub.io/237284
Change subject: Initialize nsm_mon to avoid using unintialized data
..
Initialize nsm_mon to avoid using unintialized data
Chan
On 6/22/15 2:46 AM, Dominique Martinet wrote:
> That said, there's a world difference between breaking only these who
> explicitely tried to turn something on that didn't exist yet, and
> breaking everyone's build because it's in the core part of the code.
>
Nobody broke everyone's build. It was t
Matt, clnt_vc_call() frees the memory that is later accessed by
clnt_vc_geterr. It all happens in the same *thread*. You see two stack
traces because I enabled valgrind to keep origins.
Regrads, Malahal.
Matt W. Benjamin [m...@cohortfs.com] wrote:
> Hi,
>
> So this is all happening in clnt_vc_ca
Hi,
So this is all happening in clnt_vc_call()? I'll have a look at it.
Matt
- "Malahal Naineni" wrote:
> Hi All,
>
> valgrind reported that clnt_vc_geterr() is accessing freed memory.
> Code review shows that nlm_send_async() calls clnt_call() and then
> calls
> clnt_sperror() on
Hi All,
valgrind reported that clnt_vc_geterr() is accessing freed memory.
Code review shows that nlm_send_async() calls clnt_call() and then calls
clnt_sperror() on some errors. This is clearly a bug to access rpc context
memory that was freed in a prior call. I am not familiar with RPC c
It's been a while since I worked on that part of the code.
I'm not quite sure why the config parsing was changed from using inet_pton
to getaddrinfo, probably to be more flexible with what form the option
string can take.
It really should just take the first result, or look for the SOCK_STR
>From Dominique Martinet :
Hello Philippe DENIEL,
I'd like you to do a code review. Please visit
https://review.gerrithub.io/237196
to review the following change.
Change subject: FSAL_HPSS: brings FSAL back from its ashes.
.
>From Dominique Martinet :
Dominique Martinet has uploaded a new change for review.
https://review.gerrithub.io/237176
Change subject: CMake: fix condition for proxy handle mapping
..
CMake: fix condition for proxy handle map
>From Dominique Martinet :
Dominique Martinet has uploaded a new change for review.
https://review.gerrithub.io/237177
Change subject: CMake: fix SHOOK build with prefix/lustre v2.4+
..
CMake: fix SHOOK build with prefix/lust
Hi,
This week, coverity analysis reports 4 eliminated defects and 1 new (actually
false positive)
Analysis summary report:
Files analyzed : 485
Total LoC input to cov-analyze : 189597
Functions analyzed : 4540
Paths analyzed :
13 matches
Mail list logo
