malloc: fix compile error
diff mbox series

Message ID 1572417365-24412-1-git-send-email-liusirui@huawei.com
State New
Headers show
Series
  • malloc: fix compile error
Related show

Commit Message

Liusirui Oct. 30, 2019, 6:36 a.m. UTC
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(-)

Comments

liqingqing Oct. 30, 2019, 7:27 a.m. UTC | #1
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.
Carlos O'Donell Oct. 30, 2019, 11:40 a.m. UTC | #2
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!
Florian Weimer Oct. 30, 2019, 6:39 p.m. UTC | #3
* 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.
liqingqing Oct. 31, 2019, 3:44 a.m. UTC | #4
>> 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
liqingqing Nov. 1, 2019, 7:47 a.m. UTC | #5
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
Carlos O'Donell Nov. 1, 2019, 12:49 p.m. UTC | #6
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!

Patch
diff mbox series

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;