Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sun, Mar 30, 2014 at 04:10:48PM +0100, Domingo Alvarez Duarte wrote: > I followed the code on fossil-scm with printfs on va_start/va_end using the > previous tcc stdargs implementation and it showed me that both the parent > and child do va_end on the same pointer that's why the segfault. As long as fossil-scm uses fork and not vfork, calling va_end in the parent and child can't be the reason for the segfault. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
First of all thanks for Daniel for the fix ! I followed the code on fossil-scm with printfs on va_start/va_end using the previous tcc stdargs implementation and it showed me that both the parent and child do va_end on the same pointer that's why the segfault. And as I looked on the generated code by gcc/clang/pcc all of then do not us alloc/call all is inlined so no problem of double free. So I'll not bother look any further on fossil-scm to find why it happens with the old tcc stdarg implementation. Thanks again for all of you for this great work ! On Sat, Mar 29, 2014 at 11:37 PM, Michael Matz wrote: > Hi, > > > On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote: > > clang and pcc also generates inline assembly instead of call/alloc. >> > > Yes. I haven't said the relevant stdarg functions have to use malloc. > They just need to interoperate with what the ABI says (and that's passing > by pointer). Daniel downthread is correct in that va_list itself doesn't > have to be a pointer, that was merely TCCs way of fulfilling the ABI > requirements. So he fixed it meanwhile, so I'm fine. > > The fossil-scm issue should still be investigated somewhen. TCCs old > implementation of stdarg was conforming, so changing it to something else > shouldn't affect any correctly written code (meaning that I'd suspect > either some different bug in TCC that now is merely hidden, or a bug in > fossil-scm (perhaps in their usage of stdarg functions) that's now hidden). > > > > Ciao, > Michael. > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Hi, On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote: clang and pcc also generates inline assembly instead of call/alloc. Yes. I haven't said the relevant stdarg functions have to use malloc. They just need to interoperate with what the ABI says (and that's passing by pointer). Daniel downthread is correct in that va_list itself doesn't have to be a pointer, that was merely TCCs way of fulfilling the ABI requirements. So he fixed it meanwhile, so I'm fine. The fossil-scm issue should still be investigated somewhen. TCCs old implementation of stdarg was conforming, so changing it to something else shouldn't affect any correctly written code (meaning that I'd suspect either some different bug in TCC that now is merely hidden, or a bug in fossil-scm (perhaps in their usage of stdarg functions) that's now hidden). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Hi,
On Sat, 29 Mar 2014, Domingo Alvarez Duarte wrote:
Thanks for pointing it and show an example to test !
Now going back to the original problem the original tcc implementation leaks
memory on:
void *__va_copy(struct __va_list_struct *src)
{
struct __va_list_struct *dest =
(struct __va_list_struct *)malloc(sizeof(struct __va_list_struct));
*dest = *src;
return dest;
}
No, that's not leaking memory, because a va_copy _must_ be paired with a
va_end call in client code. And that one will release the
allocated memory.
And I'll continue investigating a way to make it work with fossil-scm
for the X86_64, the problem that I saw is that there is a double free
when the process fork somehow the fossil compiled by tcc seem to not
duplicate the malloced strioneng and both the parent and child free the
same string.
That's no double free, because the process space will be unshared after
fork. I don't know what tool you used that pointed out a double free in
this specific situation, but if it really thought this situation is a
double free then it's buggy.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:52:42PM +0100, Daniel Glöckner wrote: > Or simply > > typedef struct __va_list_struct va_list[1]; Fixed in mob. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:46:26PM +0100, Daniel Glöckner wrote: > Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed > as a pointer. So we should > > typedef void *va_list[3]; Or simply typedef struct __va_list_struct va_list[1]; ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
> Errr. I see you now fiddled with that on mob. Commit c025478d7c03, > rewriting va* to not use malloc. That's completely wrong. You've > effectively changed the ABI of stdarg, and hence interoperability > with every non-TCC compiler. The public va_list on x86_64 _must_ be > a pointer. Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed as a pointer. So we should typedef void *va_list[3]; and cast that to struct __va_list_struct as needed. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
clang and pcc also generates inline assembly instead of call/alloc.
gcc -E -o check-va-gcc.c check-va.c
gcc -S -o check-va-gcc.asm check-va.c
gcc -o check-va-gcc check-va.c
clang -E -o check-va-clang.c check-va.c
clang -S -o check-va-clang.asm check-va.c
clang -o check-va-clang check-va.c
pcc -E -o check-va-pcc.c check-va.c
pcc -S -o check-va-pcc.asm check-va.c
#pcc -o check-va-pcc check-va.c
../tcc -B.. -I.. -I../include -E -o check-va-tcc.c check-va.c
../tcc -B.. -I.. -I../include -o check-va-tcc check-va.c
./check-va-gcc
./check-va-tcc
On Sat, Mar 29, 2014 at 9:38 PM, Domingo Alvarez Duarte
wrote:
> Asking gcc to generate assembler code from your test code I can see that
> gcc do not call/malloc any builtin it generates inline code so there is
> nothing to free.
> -
> .file "check-va.c"
> .text
> .type passdown, @function
> passdown:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> subq $48, %rsp
> movq %rdi, -40(%rbp)
> movq %rsi, -48(%rbp)
> leaq -32(%rbp), %rax
> movq -48(%rbp), %rdx
> movq (%rdx), %rcx
> movq %rcx, (%rax)
> movq 8(%rdx), %rcx
> movq %rcx, 8(%rax)
> movq 16(%rdx), %rdx
> movq %rdx, 16(%rax)
> leaq -32(%rbp), %rdx
> movq -40(%rbp), %rax
> movq %rdx, %rsi
> movq %rax, %rdi
> call vprintf
> movl %eax, -4(%rbp)
> movl -4(%rbp), %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE0:
> .size passdown, .-passdown
> .type myprintf, @function
> myprintf:
> .LFB1:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> subq $224, %rsp
> movq %rsi, -168(%rbp)
> movq %rdx, -160(%rbp)
> movq %rcx, -152(%rbp)
> movq %r8, -144(%rbp)
> movq %r9, -136(%rbp)
> testb %al, %al
> je .L3
> movaps %xmm0, -128(%rbp)
> movaps %xmm1, -112(%rbp)
> movaps %xmm2, -96(%rbp)
> movaps %xmm3, -80(%rbp)
> movaps %xmm4, -64(%rbp)
> movaps %xmm5, -48(%rbp)
> movaps %xmm6, -32(%rbp)
> movaps %xmm7, -16(%rbp)
> .L3:
> movq %rdi, -216(%rbp)
> movl $8, -200(%rbp)
> movl $48, -196(%rbp)
> leaq 16(%rbp), %rax
> movq %rax, -192(%rbp)
> leaq -176(%rbp), %rax
> movq %rax, -184(%rbp)
> leaq -200(%rbp), %rdx
> movq -216(%rbp), %rax
> movq %rdx, %rsi
> movq %rax, %rdi
> call passdown
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE1:
> .size myprintf, .-myprintf
> .section .rodata
> .LC1:
> .string "bla"
> .LC2:
> .string "%s %i %f\n"
> .text
> .globl main
> .type main, @function
> main:
> .LFB2:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movsd .LC0(%rip), %xmm0
> movl $42, %edx
> movl $.LC1, %esi
> movl $.LC2, %edi
> movl $1, %eax
> call myprintf
> movl $0, %eax
> popq %rbp
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE2:
> .size main, .-main
> .section .rodata
> .align 8
> .LC0:
> .long 2576980378
> .long 1071225241
> .ident "GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
> .section .note.GNU-stack,"",@progbits
>
>
>
> On Sat, Mar 29, 2014 at 9:33 PM, Domingo Alvarez Duarte <
> mingo...@gmail.com> wrote:
>
>> Thanks for pointing it and show an example to test !
>>
>> Now going back to the original problem the original tcc implementation
>> leaks memory on:
>>
>> void *__va_copy(struct __va_list_struct *src)
>> {
>> struct __va_list_struct *dest =
>> (struct __va_list_struct *)malloc(sizeof(struct
>> __va_list_struct));
>> *dest = *src;
>> return dest;
>> }
>>
>>
>> And I'll continue investigating a way to make it work with fossil-scm for
>> the X86_64, the problem that I saw is that there is a double free when the
>> process fork somehow the fossil compiled by tcc seem to not duplicate the
>> malloced strioneng and both the parent and child free the same string.
>>
>> Sounds crazy because the os should do that.
>>
>> Any idea on the memory leak and the process fork ?
>>
>> Again thanks for you time and attention !
>>
>>
>> On Sat, Mar 29, 2014 at 5:53 PM, Michael Matz wrote:
>>
>>> Hello,
>>>
>>>
>>> On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
>>>
>>> I found that on X86_64 linux if I do not free the memory on __va_end(),
the
compiled fossil-scm server works, I suspect is something with the
fork/threads.---
void __va_end(struct __va_list_struct *ap)
{
//free(ap);
}
Cheers !
>>>
>>> Errr. I see you now fiddled with that on mob. Commit c025478d7c03,
>>> rewriting va* to not use malloc. That's completely wrong. You've
>>> effectively changed the ABI of stdarg, and hence interoperability with
>>> every non-TCC compiler. The public va_list on x86_64 _must_ be a pointer.
>>> To see it breaking try e.g. this:
>>>
>>> % cat vatest.c
>>> #include
>>> #include
>>>
>>> static int passdown (const char *str, va_list ap)
>>> {
>>> int ret;
>>> va_list ap2;
>>> va_copy (ap2, ap);
>>> ret = vprintf (str, ap2);
>>> va_end (ap2);
>>> return ret;
>>> }
>>
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Asking gcc to generate assembler code from your test code I can see that
gcc do not call/malloc any builtin it generates inline code so there is
nothing to free.
-
.file "check-va.c"
.text
.type passdown, @function
passdown:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $48, %rsp
movq %rdi, -40(%rbp)
movq %rsi, -48(%rbp)
leaq -32(%rbp), %rax
movq -48(%rbp), %rdx
movq (%rdx), %rcx
movq %rcx, (%rax)
movq 8(%rdx), %rcx
movq %rcx, 8(%rax)
movq 16(%rdx), %rdx
movq %rdx, 16(%rax)
leaq -32(%rbp), %rdx
movq -40(%rbp), %rax
movq %rdx, %rsi
movq %rax, %rdi
call vprintf
movl %eax, -4(%rbp)
movl -4(%rbp), %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size passdown, .-passdown
.type myprintf, @function
myprintf:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $224, %rsp
movq %rsi, -168(%rbp)
movq %rdx, -160(%rbp)
movq %rcx, -152(%rbp)
movq %r8, -144(%rbp)
movq %r9, -136(%rbp)
testb %al, %al
je .L3
movaps %xmm0, -128(%rbp)
movaps %xmm1, -112(%rbp)
movaps %xmm2, -96(%rbp)
movaps %xmm3, -80(%rbp)
movaps %xmm4, -64(%rbp)
movaps %xmm5, -48(%rbp)
movaps %xmm6, -32(%rbp)
movaps %xmm7, -16(%rbp)
.L3:
movq %rdi, -216(%rbp)
movl $8, -200(%rbp)
movl $48, -196(%rbp)
leaq 16(%rbp), %rax
movq %rax, -192(%rbp)
leaq -176(%rbp), %rax
movq %rax, -184(%rbp)
leaq -200(%rbp), %rdx
movq -216(%rbp), %rax
movq %rdx, %rsi
movq %rax, %rdi
call passdown
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size myprintf, .-myprintf
.section .rodata
.LC1:
.string "bla"
.LC2:
.string "%s %i %f\n"
.text
.globl main
.type main, @function
main:
.LFB2:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movsd .LC0(%rip), %xmm0
movl $42, %edx
movl $.LC1, %esi
movl $.LC2, %edi
movl $1, %eax
call myprintf
movl $0, %eax
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2:
.size main, .-main
.section .rodata
.align 8
.LC0:
.long 2576980378
.long 1071225241
.ident "GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
.section .note.GNU-stack,"",@progbits
On Sat, Mar 29, 2014 at 9:33 PM, Domingo Alvarez Duarte
wrote:
> Thanks for pointing it and show an example to test !
>
> Now going back to the original problem the original tcc implementation
> leaks memory on:
>
> void *__va_copy(struct __va_list_struct *src)
> {
> struct __va_list_struct *dest =
> (struct __va_list_struct *)malloc(sizeof(struct __va_list_struct));
> *dest = *src;
> return dest;
> }
>
>
> And I'll continue investigating a way to make it work with fossil-scm for
> the X86_64, the problem that I saw is that there is a double free when the
> process fork somehow the fossil compiled by tcc seem to not duplicate the
> malloced strioneng and both the parent and child free the same string.
>
> Sounds crazy because the os should do that.
>
> Any idea on the memory leak and the process fork ?
>
> Again thanks for you time and attention !
>
>
> On Sat, Mar 29, 2014 at 5:53 PM, Michael Matz wrote:
>
>> Hello,
>>
>>
>> On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
>>
>> I found that on X86_64 linux if I do not free the memory on __va_end(),
>>> the
>>> compiled fossil-scm server works, I suspect is something with the
>>> fork/threads.---
>>> void __va_end(struct __va_list_struct *ap)
>>> {
>>> //free(ap);
>>> }
>>>
>>> Cheers !
>>>
>>
>> Errr. I see you now fiddled with that on mob. Commit c025478d7c03,
>> rewriting va* to not use malloc. That's completely wrong. You've
>> effectively changed the ABI of stdarg, and hence interoperability with
>> every non-TCC compiler. The public va_list on x86_64 _must_ be a pointer.
>> To see it breaking try e.g. this:
>>
>> % cat vatest.c
>> #include
>> #include
>>
>> static int passdown (const char *str, va_list ap)
>> {
>> int ret;
>> va_list ap2;
>> va_copy (ap2, ap);
>> ret = vprintf (str, ap2);
>> va_end (ap2);
>> return ret;
>> }
>>
>> static int myprintf (const char *str, ...)
>> {
>> va_list ap;
>> va_start (ap, str);
>> passdown (str, ap);
>> va_end (ap);
>> }
>>
>> int main ()
>> {
>> myprintf ("%s %i %f\n", "bla", 42, 0.4);
>> return 0;
>> }
>>
>> When executed it must print:
>> bla 42 0.40
>>
>> Before your patch it does, after your patch it prints garbage (on my
>> system " 134514261 0.00") (without the va_copy and ap2 it even just
>> segfaults now, though strictly speaking that's invalid stdarg usage).
>> Please revert.
>>
>> If you could please _discuss_ changes in parts you don't completely
>> understand on the list before making nilly-willy changes? Just because
>> fossil-scm "works" after your patching doesn't mean much if you don't know
>> _why_ fossil-scm didn't work before, and especially doesn't mean that the
>> change was even correct.
>>
>>
>> Ciao,
>> Michael.
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Thanks for pointing it and show an example to test !
Now going back to the original problem the original tcc implementation
leaks memory on:
void *__va_copy(struct __va_list_struct *src)
{
struct __va_list_struct *dest =
(struct __va_list_struct *)malloc(sizeof(struct __va_list_struct));
*dest = *src;
return dest;
}
And I'll continue investigating a way to make it work with fossil-scm for
the X86_64, the problem that I saw is that there is a double free when the
process fork somehow the fossil compiled by tcc seem to not duplicate the
malloced strioneng and both the parent and child free the same string.
Sounds crazy because the os should do that.
Any idea on the memory leak and the process fork ?
Again thanks for you time and attention !
On Sat, Mar 29, 2014 at 5:53 PM, Michael Matz wrote:
> Hello,
>
>
> On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
>
> I found that on X86_64 linux if I do not free the memory on __va_end(),
>> the
>> compiled fossil-scm server works, I suspect is something with the
>> fork/threads.---
>> void __va_end(struct __va_list_struct *ap)
>> {
>> //free(ap);
>> }
>>
>> Cheers !
>>
>
> Errr. I see you now fiddled with that on mob. Commit c025478d7c03,
> rewriting va* to not use malloc. That's completely wrong. You've
> effectively changed the ABI of stdarg, and hence interoperability with
> every non-TCC compiler. The public va_list on x86_64 _must_ be a pointer.
> To see it breaking try e.g. this:
>
> % cat vatest.c
> #include
> #include
>
> static int passdown (const char *str, va_list ap)
> {
> int ret;
> va_list ap2;
> va_copy (ap2, ap);
> ret = vprintf (str, ap2);
> va_end (ap2);
> return ret;
> }
>
> static int myprintf (const char *str, ...)
> {
> va_list ap;
> va_start (ap, str);
> passdown (str, ap);
> va_end (ap);
> }
>
> int main ()
> {
> myprintf ("%s %i %f\n", "bla", 42, 0.4);
> return 0;
> }
>
> When executed it must print:
> bla 42 0.40
>
> Before your patch it does, after your patch it prints garbage (on my
> system " 134514261 0.00") (without the va_copy and ap2 it even just
> segfaults now, though strictly speaking that's invalid stdarg usage).
> Please revert.
>
> If you could please _discuss_ changes in parts you don't completely
> understand on the list before making nilly-willy changes? Just because
> fossil-scm "works" after your patching doesn't mean much if you don't know
> _why_ fossil-scm didn't work before, and especially doesn't mean that the
> change was even correct.
>
>
> Ciao,
> Michael.
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
Hello,
On Fri, 28 Mar 2014, Domingo Alvarez Duarte wrote:
I found that on X86_64 linux if I do not free the memory on __va_end(), the
compiled fossil-scm server works, I suspect is something with the
fork/threads.---
void __va_end(struct __va_list_struct *ap)
{
//free(ap);
}
Cheers !
Errr. I see you now fiddled with that on mob. Commit c025478d7c03,
rewriting va* to not use malloc. That's completely wrong. You've
effectively changed the ABI of stdarg, and hence interoperability with
every non-TCC compiler. The public va_list on x86_64 _must_ be a pointer.
To see it breaking try e.g. this:
% cat vatest.c
#include
#include
static int passdown (const char *str, va_list ap)
{
int ret;
va_list ap2;
va_copy (ap2, ap);
ret = vprintf (str, ap2);
va_end (ap2);
return ret;
}
static int myprintf (const char *str, ...)
{
va_list ap;
va_start (ap, str);
passdown (str, ap);
va_end (ap);
}
int main ()
{
myprintf ("%s %i %f\n", "bla", 42, 0.4);
return 0;
}
When executed it must print:
bla 42 0.40
Before your patch it does, after your patch it prints garbage (on my
system " 134514261 0.00") (without the va_copy and ap2 it even just
segfaults now, though strictly speaking that's invalid stdarg usage).
Please revert.
If you could please _discuss_ changes in parts you don't completely
understand on the list before making nilly-willy changes? Just because
fossil-scm "works" after your patching doesn't mean much if you don't know
_why_ fossil-scm didn't work before, and especially doesn't mean that the
change was even correct.
Ciao,
Michael.___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
The strange thing is that on linux 32bits it works fine without the las
hack.
On Fri, Mar 28, 2014 at 5:05 PM, Domingo Alvarez Duarte
wrote:
> I found that on X86_64 linux if I do not free the memory on __va_end(),
> the compiled fossil-scm server works, I suspect is something with the
> fork/threads.
> ---
> void __va_end(struct __va_list_struct *ap)
> {
> //free(ap);
> }
>
> Cheers !
>
>
> On Thu, Mar 27, 2014 at 12:23 PM, Domingo Alvarez Duarte <
> mingo...@gmail.com> wrote:
>
>> When I say that fossil-scm compiled with tcc segfault I mean on linux
>> X86_64, but on linux 32bits it does compile and work fine.
>> So it's something specific to 64 bits.
>>
>> Cheers !
>>
>>
>> On Thu, Mar 27, 2014 at 11:50 AM, Domingo Alvarez Duarte <
>> mingo...@gmail.com> wrote:
>>
>>> Hello !
>>>
>>> Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean
>>> it does compile but segfault after a few malloc calls.
>>>
>>> Cheers !
>>>
>>
>>
>
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
I found that on X86_64 linux if I do not free the memory on __va_end(), the
compiled fossil-scm server works, I suspect is something with the
fork/threads.
---
void __va_end(struct __va_list_struct *ap)
{
//free(ap);
}
Cheers !
On Thu, Mar 27, 2014 at 12:23 PM, Domingo Alvarez Duarte wrote:
> When I say that fossil-scm compiled with tcc segfault I mean on linux
> X86_64, but on linux 32bits it does compile and work fine.
> So it's something specific to 64 bits.
>
> Cheers !
>
>
> On Thu, Mar 27, 2014 at 11:50 AM, Domingo Alvarez Duarte <
> mingo...@gmail.com> wrote:
>
>> Hello !
>>
>> Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean
>> it does compile but segfault after a few malloc calls.
>>
>> Cheers !
>>
>
>
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On arm the program "bld/translate" compiled with tcc also segfault . On Thu, Mar 27, 2014 at 12:23 PM, Domingo Alvarez Duarte wrote: > When I say that fossil-scm compiled with tcc segfault I mean on linux > X86_64, but on linux 32bits it does compile and work fine. > So it's something specific to 64 bits. > > Cheers ! > > > On Thu, Mar 27, 2014 at 11:50 AM, Domingo Alvarez Duarte < > mingo...@gmail.com> wrote: > >> Hello ! >> >> Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean >> it does compile but segfault after a few malloc calls. >> >> Cheers ! >> > > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
When I say that fossil-scm compiled with tcc segfault I mean on linux X86_64, but on linux 32bits it does compile and work fine. So it's something specific to 64 bits. Cheers ! On Thu, Mar 27, 2014 at 11:50 AM, Domingo Alvarez Duarte wrote: > Hello ! > > Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean > it does compile but segfault after a few malloc calls. > > Cheers ! > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Tinycc from git still can't compile fossil-scm
Hello ! Even with our latest bug fixes tinycc fail to compile fossil-scm, I mean it does compile but segfault after a few malloc calls. Cheers ! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
