| Message ID | 1572417365-24412-1-git-send-email-liusirui@huawei.com |
|---|---|
| State | New |
| Headers | show |
| Series | malloc: fix compile error | expand |
On 2019/10/30 14:36, Liusirui wrote: > Since e9c4fe93b3855239752819303ca377dff0ed0553, the commit changes struct > malloc_chunk member "size" to "mchunk_size". This cause a compile error > in function dump_heap, if macros MALLOC_DEBUG has defined and the value is > larger 1. > > --- > malloc/arena.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/malloc/arena.c b/malloc/arena.c > index 74815ac..be5c9f9 100644 > --- a/malloc/arena.c > +++ b/malloc/arena.c > @@ -419,13 +419,13 @@ dump_heap (heap_info *heap) > ~MALLOC_ALIGN_MASK); > for (;; ) > { > - fprintf (stderr, "chunk %p size %10lx", p, (long) p->size); > + fprintf (stderr, "chunk %p size %10lx", p, (long) chunksize_nomask(p)); > if (p == top (heap->ar_ptr)) > { > fprintf (stderr, " (top)\n"); > break; > } > - else if (p->size == (0 | PREV_INUSE)) > + else if (chunksize_nomask(p) == (0 | PREV_INUSE)) > { > fprintf (stderr, " (fence)\n"); > break; > I think you can give more details about the error like the compile step. and so that the other guys may get more information.
On 10/30/19 3:27 AM, liqingqing wrote: > On 2019/10/30 14:36, Liusirui wrote: >> Since e9c4fe93b3855239752819303ca377dff0ed0553, the commit changes struct >> malloc_chunk member "size" to "mchunk_size". This cause a compile error >> in function dump_heap, if macros MALLOC_DEBUG has defined and the value is >> larger 1. >> >> --- >> malloc/arena.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/malloc/arena.c b/malloc/arena.c >> index 74815ac..be5c9f9 100644 >> --- a/malloc/arena.c >> +++ b/malloc/arena.c >> @@ -419,13 +419,13 @@ dump_heap (heap_info *heap) >> ~MALLOC_ALIGN_MASK); >> for (;; ) >> { >> - fprintf (stderr, "chunk %p size %10lx", p, (long) p->size); >> + fprintf (stderr, "chunk %p size %10lx", p, (long) chunksize_nomask(p)); >> if (p == top (heap->ar_ptr)) >> { >> fprintf (stderr, " (top)\n"); >> break; >> } >> - else if (p->size == (0 | PREV_INUSE)) >> + else if (chunksize_nomask(p) == (0 | PREV_INUSE)) >> { >> fprintf (stderr, " (fence)\n"); >> break; >> > > I think you can give more details about the error like the compile > step. and so that the other guys may get more information. > Agreed. The commit message should say which error and which compiler version generated the error. We still can't accept patches from Huawei yet because copyright assignment has not been completed. But thanks for the review!
* liqingqing: > On 2019/10/30 14:36, Liusirui wrote: >> Since e9c4fe93b3855239752819303ca377dff0ed0553, the commit changes struct >> malloc_chunk member "size" to "mchunk_size". This cause a compile error >> in function dump_heap, if macros MALLOC_DEBUG has defined and the value is >> larger 1. >> >> --- >> malloc/arena.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/malloc/arena.c b/malloc/arena.c >> index 74815ac..be5c9f9 100644 >> --- a/malloc/arena.c >> +++ b/malloc/arena.c >> @@ -419,13 +419,13 @@ dump_heap (heap_info *heap) >> ~MALLOC_ALIGN_MASK); >> for (;; ) >> { >> - fprintf (stderr, "chunk %p size %10lx", p, (long) p->size); >> + fprintf (stderr, "chunk %p size %10lx", p, (long) chunksize_nomask(p)); >> if (p == top (heap->ar_ptr)) >> { >> fprintf (stderr, " (top)\n"); >> break; >> } >> - else if (p->size == (0 | PREV_INUSE)) >> + else if (chunksize_nomask(p) == (0 | PREV_INUSE)) >> { >> fprintf (stderr, " (fence)\n"); >> break; >> > > I think you can give more details about the error like the compile step. > and so that the other guys may get more information. The problem is that the accessor conversion was not extended to the MALLOC_DEBUG conditional areas of the code. The commit message could perhaps be worded a little bit clearer in this regard.
>> I think you can give more details about the error like the compile >> step. and so that the other guys may get more information. >> > > Agreed. The commit message should say which error and which compiler > version generated the error. > > We still can't accept patches from Huawei yet because copyright assignment > has not been completed. But thanks for the review! > hello Carlos, how are you? we found that other people which is from Huawei also have the same problem. below is the discussion. https://sourceware.org/ml/libc-alpha/2019-10/msg00905.html we checked the contribution checklist again, and we also have the same question: even if we just fix a bug in the situation that we has already completed an fsp copyright assignment, the code also can not be accepted? what we need to do next? we expect your or others more helps, thank you. liqingqingqing
ping again On 2019/10/31 11:44, liqingqing wrote: >>> I think you can give more details about the error like the compile >>> step. and so that the other guys may get more information. >>> >> >> Agreed. The commit message should say which error and which compiler >> version generated the error. >> >> We still can't accept patches from Huawei yet because copyright >> assignment >> has not been completed. But thanks for the review! >> > > hello Carlos, how are you? > we found that other people which is from Huawei also have the same > problem. below is the discussion. > https://sourceware.org/ml/libc-alpha/2019-10/msg00905.html > > we checked the contribution checklist again, and we also have the same > question: even if we just fix a bug in the situation that we has already > completed an fsp copyright assignment, the code also can not be > accepted? what we need to do next? we expect your or others more > helps, thank you. > hello carlos, I checked the contribution checklist again and i think maybe it has two different situations. the FSF copy assignment section said that only "legally signification" required copyright assigment. here is the copy: "The Free Software Foundation (holder of the glibc copyrights) requires copyright assignment for all legally significant changes by a particular author (read not a company). This webpage describes the copyright assignment requirements." and the legally signification changes is defined like that: http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant section 6.2 Legally Significant Changes : "If a person contributes more than around 15 lines of code and/or text that is legally significant for copyright purposes, we need copyright papers for that contribution, as described above. A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when." so I think for few changes like a bugfix, the patche can be accepted. and for "legally significant changes" , we also need your help: what is possible contribute ways? a public huawei account which is approved by the supervisor? or an huawei's public copyright assignment? can you give me more suggestions? thank you. liqingqing
On 11/1/19 3:47 AM, liqingqing wrote: > so I think for few changes like a bugfix, the patche can be > accepted. and for "legally significant changes" , we also need your > help: what is possible contribute ways? a public huawei account > which is approved by the supervisor? or an huawei's public copyright > assignment? The goal right now is to get a "corporate" assignment in place of Huawei. It would allow all Huawei employees to submit code to glibc. Xuelei (on TO:) is already working with the FSF on the corporate assignment. I would suggest coordinating with Xuelei. We can not accept code from Huawei employees until the corporate assignment is signed. My sincerest apologies for the delay. I look forward to accepting more code from such motivated and dedicated developers!
diff --git a/malloc/arena.c b/malloc/arena.c index 74815ac..be5c9f9 100644 --- a/malloc/arena.c +++ b/malloc/arena.c @@ -419,13 +419,13 @@ dump_heap (heap_info *heap) ~MALLOC_ALIGN_MASK); for (;; ) { - fprintf (stderr, "chunk %p size %10lx", p, (long) p->size); + fprintf (stderr, "chunk %p size %10lx", p, (long) chunksize_nomask(p)); if (p == top (heap->ar_ptr)) { fprintf (stderr, " (top)\n"); break; } - else if (p->size == (0 | PREV_INUSE)) + else if (chunksize_nomask(p) == (0 | PREV_INUSE)) { fprintf (stderr, " (fence)\n"); break;