Oops! Forgot to CC.
--- Begin Message ---
Ben Hutchings wrote:
I didn't keep it. There are warnings about various format strings using
the wrong size (%ld for an argument of type size_t; should be %zd). Due
to use of -Werror these are fatal.
Ben.
I'll be the first to admit that treedb et al are primarily 64 bit
projects, due
to the fact that they use memory maps (exclusively, for now).
As for %zd, I never even heard of it until your email - I had to look it
up in
libc's info pages - I'll change my code as soon as I finish knocking
v3c-repo
into shape.
I was also hoping that someone involved with gcc/kdbg/gdb could shine
some light
on how the code could run away with itself without being caught, seeing
as I'm
compiling with -fstack-protector-all, so it must be something else.
I was going to reply with this program.
int main(int argc, char *argv[])
{
return main(argc, argv);
}
But kdbg catches the segfault and the line number with no problem.
Then I tried
#include <unistd.h>
#include <sys/mman.h>
int main(int argc, char *argv[])
{
size_t page_size = (size_t)sysconf(_SC_PAGESIZE);
void * p = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_ANON,
0, 0);
return main(argc, argv);
}
Kdbg rather unhelpfully indicated that the segfault happened at the
sysconf() call site.
This lead me to conclude that the problem may be some permutation of
- gcc's code generation
- memory maps
- stack overflow
- other factors I hadn't considered
I just tried the above examples above on a Squeeze'ified Lenny
(Squeeze's kernel, compiler
, kdbg, git), and they don't affect system stability, eat all available
memory, or continue
to run after kdbg reports a segfault.
I used v3c-tryout (a shell script that's part of the v3c package) to
recreate the problem
just now, with
./v3c-tryout v3c-repo-0.2.0-01-testing tryout (from my v3c directory)
../tryout/enter-env
[in the sandbox sub-shell]
cd v3c-repo-0.2.0-01-testing
ulimit -S -v $((1024 * 1000))
make check
The script I provided does the same, but without the ulimit call.
The ulimit call causes the test to fail and "make check" to continue -
the value is so
large so as to allow gcc/g++ to proceed (it may be way too large).
Philip
--- End Message ---
