From: Steve Blinkhorn <steve@pr...> - 2003-02-27 14:44:20
I seem to have hit on a difference between NT4 and 2000 in trying to
track down a crash-inducing bug. Yesterday I asked about
size_of_stack_reserve__(), because that is what gdb tells me is the
last thing with a symbol table entry before a segmentation fault.
However, when I run the same executable on NT4 rather than Win2000,
there is no problem. Because the place where things go wrong
involves environment access, my guess is that either putenv or getenv,
or possibly both, have changed, or possibly the stub library for
kernel32.dll that I am linking against is wrong for Win2000.
The problem is a dynamic one: the same code is used repeatedly - many
many times - before we hit a problem, and I wonder whether in Win2000
writing to the environment is less flexible, maybe not such careful
garbage collection and reallocation.
Does anyone have any experience of differences in this area? I have
been using the environment for the purpose in question, viz. flexible
interfacing between highly dynamic executables, for around 15 years,
and would rather not have to completely re-engineer a software system
because Micro$oft have changed the functionality of their
implementation of ANSI-standard features.
Steve Blinkhorn wrote:
> I seem to have hit on a difference between NT4 and 2000 in trying to
> track down a crash-inducing bug. [...]
> However, when I run the same executable on NT4 rather than Win2000,
> there is no problem. [...]
I had a similar experience: My program would fail on a colleague's
machine running Win2000, but work fine (using the same input file!)
on my WinNT machine.
> The problem is a dynamic one: the same code is used repeatedly - many
> many times - before we hit a problem,
Same here - it worked (even) on Win2000 using smaller input files.
> and I wonder whether in Win2000
> writing to the environment is less flexible, maybe not such careful
> garbage collection and reallocation.
My program does not do "putenv()", but it builds tables from the
identifiers in the input file (it is a kind of compiler).
The tables are dynamically extended using "malloc()".
I solved the problem by increasing the initial table size so much
(machines have got more RAM now than in earlier times) that
"malloc()" is needed less often (or not at all).
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)