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
[email protected]
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 : [EMAIL PROTECTED]
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
[email protected]
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 : [EMAIL PROTECTED]
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
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
