On Fri, Mar 9, 2018 at 8:33 AM, Michael Meskes <meskes@postgresql.org> wrote:
>> Details: In function main(), the memory hold by variable
>> output_filename is
>> freed at line 329. It then tries to parse the next command option.
>> The freed
>> memory will be freed again at line 478 if a crafted option bypass the
>> memory
>> allocation at line 316. I think set output_filename to NULL after the
>> free
>> operation at line 329 will fix the issue.
>> ...
>
> I haven't had time yet to look into this, but to speed things up, would
> you have an example where the double free actually happens?
>
> Thanks.
>
> Michael
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Meskes at (Debian|Postgresql) dot Org
> Jabber: michael at xmpp dot meskes dot org
> VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
>
You can see it fairly easily by doing the following:
touch test.c;
chmod 0444 test.c;
echo "" | ./ecpg test.c -;
On my Mac I occasionally see the following:
ecpg(19715,0x7fffdd46b3c0) malloc: *** error for object
0x7fa92d402ed0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
I don't really understand how the double-free detection works, though,
and the error does not always appear.
There is a separate problem, when test.c *is* writeable and is
followed by an - (stdout) argument. In this case there is another
double free. Attached is a fix for both.
