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 <matz....@frakked.de> 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 <stdio.h>
> #include <stdarg.h>
>
> 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.400000
>
> Before your patch it does, after your patch it prints garbage (on my
> system " 134514261 0.000000") (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
