Re: [Tinycc-devel] Crash report for [mob:3054a76]

[Michael Matz]

Hi,

On Wed, 9 Nov 2016, Steffen Nurpmeso wrote:

> Hello.
> 
> Michael Matz <address@hidden> wrote:
>  |On Tue, 8 Nov 2016, Steffen Nurpmeso wrote:
>  ...
>  |> cc': corrupted double-linked list: 0x000000000065c0f0 ***
>  |
>  |Something in tcc is probably overwriting random memory which happens to be 
>  |meta info malloc is using for its own implementation leading to the 
>  |ovserved abort (which basically is a consistency check on that internal 
>  |data).  valgrind often helps in identifying the real cause, so do:
> 
> The attached diff fixes the issue for me.

So, the patch was:

> diff --git a/tccelf.c b/tccelf.c
> index 9ed2484..52db06a 100644
> --- a/tccelf.c
> +++ b/tccelf.c
> @@ -128,9 +128,11 @@ ST_FUNC void tccelf_delete(TCCState *s1)
>  ST_FUNC Section *new_section(TCCState *s1, const char *name, int sh_type, 
> int sh_flags)
>  {
>      Section *sec;
> +    size_t len;
>  
> -    sec = tcc_mallocz(sizeof(Section) + strlen(name));
> -    strcpy(sec->name, name);
> +    len = strlen(name) +1;
> +    sec = tcc_mallocz(sizeof(Section) + len);
> +    memcpy(sec->name, name, len);
>      sec->sh_type = sh_type;
>      sec->sh_flags = sh_flags;
>      switch(sh_type) {

Maybe it helps but if so for unknown reasons.  The type Section has as 
last member "char name[1]", that is, sizeof(Section) already contains the 
+1.  The above merely overallocates the struct by another byte.  Can you 
show use valgrind output, or alternatively give us the .o file that causes 
the crash?

> @@ -695,8 +697,9 @@ ST_FUNC void relocate_section(TCCState *s1, Section *s)
> #endif
>  
>      for_each_elem(sr, 0, rel, ElfW_Rel) {
> -        ptr = s->data + rel->r_offset;
> +        section_ptr_add(s, 8);
>  
> +        ptr = s->data + rel->r_offset;
>          sym_index = ELFW(R_SYM)(rel->r_info);
>          sym = &((ElfW(Sym) *)symtab_section->data)[sym_index];
>          val = sym->st_value;

No, that's certainly wrong.  You don't want to enlarge a section by 8 
bytes for every relocation applied to it.  It must already be large enough 
to cover the relocations place, otherwise the one creating the reloc did 
something wrong.


Ciao,
Michael.