Jacques Caron wrote:
> Try this:
>
> cat >test_4096.c <<EOF
> #include <stdio.h>
>
> int main()
> {
>         unsigned long long a;
>
>         a = -4096;
>
>         printf("%llu\n",a);
>
>         return 0;
> }
> EOF
> cc -g -Wall test_4096.c -o test_4096
> ./test_4096
>
> -4096 is represented as 0xfffffffffffff000 (as a signed 64 bit 
> integer). If you cast it to an unsigned 64 bit integer, you get 
> 18446744073709547520.
>
> The probability that something calls malloc requesting 18 billion 
> gigabytes is low. The probability that something calls malloc 
> requesting a negative size is much higher.
>
> You might want to try strace'ing a one-liner that does a "malloc(-1)" 
> (or more certainly "malloc(-4097)" depending on how the "rounding" is 
> done?) just for fun :-)
>
> cat >test_malloc.c <<EOF
> #include <stdlib.h>
>
> int main()
> {
>         malloc(-1);
>         return 0;
> }
> EOF
> cc -g -Wall test_malloc.c -o test_malloc
> strace ./test_malloc
>
> Results differ from platform to platform, depending mainly on the 
> specific implementation of malloc. FreeBSD doesn't yield any "fun" 
> results, but apparently your OS does.
I've tested it on the host and did not get any error with a negative 
value or a big value :

cat test_malloc.c

#include <stdlib.h>
#include <stdio.h>

int main()
{
        printf("malloc(-4096)\n");
        malloc(-4096);
        printf("malloc(18446744073709547520)\n");
        malloc(18446744073709547520);
        return 0;
}

cc -g -w test_malloc.c -o test_malloc

 ./test_malloc
malloc(-4096)
malloc(18446744073709547520)

no segmentation fault, and the strace command shows :

write(1, "malloc(-4096)\n", 14malloc(-4096)
)         = 14
brk(0)                                  = 0x501000
brk(0x521000)                           = 0x521000
mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2b78f91d1000
munmap(0x2b78f91d1000, 192512)          = 0
munmap(0x2b78f9300000, 856064)          = 0
mprotect(0x2b78f9200000, 131072, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2b78f9300000
munmap(0x2b78f9400000, 1048576)         = 0
mprotect(0x2b78f9300000, 131072, PROT_READ|PROT_WRITE) = 0
munmap(0x2b78f9300000, 1048576)         = 0
write(1, "malloc(18446744073709547520)\n", 29malloc(18446744073709547520)
) = 29
mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2b78f9300000
munmap(0x2b78f9400000, 1048576)         = 0
mprotect(0x2b78f9300000, 131072, PROT_READ|PROT_WRITE) = 0
munmap(0x2b78f9300000, 1048576)         = 0
munmap(0x2b78f8e94000, 4096)            = 0
exit_group(0)                           = ?
Process 15518 detached

Regards

>
> I have gone quickly through the slonik source, including the flex and 
> bison generated code, and I don't offhand see any reason for a 
> negative malloc to happen, but there must be a case where something 
> ends up requesting a negative number of bytes. My guess was around the 
> yyleng manipulation, but it seems (?) to be correct, so it must be 
> somewhere else, or it is your version of flex or bison that is buggy.
>
> What are your versions of flex and bison?
>
> Jacques.
>
> At 21:53 11/06/2008, Cyril SCETBON wrote:
>
>
>> Jacques Caron wrote:
>>> At 11:44 06/06/2008, Cyril SCETBON wrote:
>>>> Hi guys,
>>>>
>>>> When I try to create a lot of set slonik dies with segmentation 
>>>> fault message. The only way to succeed is to split the file 
>>>> containing the create set statement and to try them one by one or 
>>>> two by two. When I use strace on slonik it displays :
>>>>
>>>> read(3, "#--\n# Slony-I organizes tables i"..., 8192) = 8192
>>>> read(3, "d table (set id=5, origin=201, i"..., 8192) = 8192
>>>> read(3, ");\nset add table (set id=9, orig"..., 8192) = 8192
>>>> mmap(NULL, 18446744073709547520, PROT_READ|PROT_WRITE, 
>>>> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>>>
>>> FYI, the mmap size is the (unsigned 64 bit integer) equivalent of 
>>> -4096, so it looks like "something" attempted a negative size malloc 
>>> (that got rounded to -4096, a multiple of the page size). Not quite 
>>> sure which piece of code could lead to that result...
>> the type is an unsigned integer. So if the value is too big a cast 
>> occurs that should not give a negative value, but a shorter value...
>>>
>>> Jacques.
>>>
>>> _______________________________________________
>>> Slony1-general mailing list
>>> Slony1-general at lists.slony.info
>>> http://lists.slony.info/mailman/listinfo/slony1-general
>>
>> -- 
>> Cyril SCETBON - Ingénieur bases de données
>> AUSY pour France Télécom - OPF/PORTAILS/DOP/HEBEX
>>
>> Tél : +33 (0)4 97 12 87 60
>> Jabber : cscetbon at jabber.org
>> France Telecom - Orange
>> 790 Avenue du Docteur Maurice Donat Bâtiment Marco Polo C2 - Bureau 202
>> 06250 Mougins
>> France
>>
>> ***********************************
>> Ce message et toutes les pieces jointes (ci-apres le 'message') sont
>> confidentiels et etablis a l'intention exclusive de ses destinataires.
>> Toute utilisation ou diffusion non autorisee est interdite.
>> Tout message electronique est susceptible d'alteration. Le Groupe France
>> Telecom decline toute responsabilite au titre de ce message s'il a ete
>> altere, deforme ou falsifie.
>> Si vous n'etes pas destinataire de ce message, merci de le detruire
>> immediatement et d'avertir l'expediteur.
>> ***********************************
>> This message and any attachments (the 'message') are confidential and
>> intended solely for the addressees.
>> Any unauthorised use or dissemination is prohibited.
>> Messages are susceptible to alteration. France Telecom Group shall 
>> not be
>> liable for the message if altered, changed or falsified.
>> If you are not recipient of this message, please cancel it 
>> immediately and
>> inform the sender.
>> ************************************
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general

-- 
Cyril SCETBON - Ingénieur bases de données
AUSY pour France Télécom - OPF/PORTAILS/DOP/HEBEX

Tél : +33 (0)4 97 12 87 60
Jabber : cscetbon at jabber.org
France Telecom - Orange
790 Avenue du Docteur Maurice Donat 
Bâtiment Marco Polo C2 - Bureau 202
06250 Mougins
France

***********************************
Ce message et toutes les pieces jointes (ci-apres le 'message') sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Le Groupe France
Telecom decline toute responsabilite au titre de ce message s'il a ete
altere, deforme ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
***********************************
This message and any attachments (the 'message') are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. France Telecom Group shall not be
liable for the message if altered, changed or falsified.
If you are not recipient of this message, please cancel it immediately and
inform the sender.
************************************