Help request for debugging ICS

[Rein Halbersma]

I thought in C it is guaranteed that uninitialized global variables start with value 0. So if the OS does ot guarantee this behavior on loading an executable image, the memset must be hidden somewhere in the startup code that eventually calls main().

Nooooooo... There is no such guarantee.

Actually, there is. In contrast to local variables, C and C++ by default zero-initialize global and static variables at program startup time. For local variables the overhead is too large of course. See http://stackoverflow.com/questions/2091 ... ult-values

[syzygy]

I thought in C it is guaranteed that uninitialized global variables start with value 0. So if the OS does ot guarantee this behavior on loading an executable image, the memset must be hidden somewhere in the startup code that eventually calls main().

Nooooooo... There is no such guarantee.

Why not first check the relevant standard before making unsubstantiated false statements? Or just google...

[jshriver]

Since I ran OICS using your codebase I know the feeling and would be willing to help you out.

backtrace from what I remember was actually just a shell script that did some funky gdb stuff. I dug it up once 3-4 years ago.

Feel free to email me jshriver@gmail.com

[jshriver]

Not sure what flavor of Linux you are running but did you recently do an update?

ICS and it's code was very um... let's say specific to things. I could easily see an updated libc and various libs causing problems due to legacy code being removed

[jshriver]

After many months of flawless running, the ICS on which I organize the monthly blitz tournaments suddenly became crash prone in October, and now typically crashes within the hour. Nothing was changed, neither in the ICS nor in the OS of the VPS it is running on.

Any chance you upgraded the compiler?

This very much! When I ran OICS I had to use the older gcc 2.95 (?) compiler to keep things kosher. Mamer even more so.

[hgm]

I am trying to silence the flood of warnings that compiling the ICS produces, to be able to see if there is anything serious there. But can anyone explain me how it is possible that the following code:

Code: Select all

static void t_sft(const char *want, struct t_tree *t)
{
  if (t) {
    int cmp = strncmp(want, &t->name, strlen(want));
    if &#40;cmp <= 0&#41;		/* if want <= this one, look left */
      t_sft&#40;want, t->left&#41;;
    if &#40;t_buffersize && &#40;cmp == 0&#41;) &#123;	/* if a match, add it to buffer */
      t_buffersize--;
      *t_buffer++ = &&#40;t->name&#41;;
    &#125;
    if &#40;cmp >= 0&#41;		/* if want >= this one, look right */
      t_sft&#40;want, t->right&#41;;
  &#125;
&#125;

Produces (several times) the warning

utils.c:673: warning: passing argument 1 of ‘strlen’ from incompatible pointer type
/usr/include/string.h:397: note: expected ‘const char *’ but argument is of type ‘char (*)[100]’

? The strlen in the above code does have argument 'want', which is a formal parameter of the function declared as (const char *). So where does this 'char (*)[100]' nonsense from? Does it try to in-line the routine somewhere, in a place where it is called with an actual parameter of the wrong type?

[flok]

Maybe you can put it on github?
Then everybody can chime in to fix/improve things.

[hgm]

There already is a version on github. By ddugovic. It is in my own on-line git repository too.

[hgm]

Hmm, when I remove the & from &t->name, all the non-sensical warnings and their duplicats disappear. Indeed t->name is an array, which is an address, and I have no idea how you could take the address of an address. Seems to me that this should be an error, rather than a warning. It surely confused the compiler, making it completely lose track of the type of other, unrelated variables.

[petero2]

Hmm, when I remove the & from &t->name, all the non-sensical warnings and their duplicats disappear. Indeed t->name is an array, which is an address, and I have no idea how you could take the address of an address. Seems to me that this should be an error, rather than a warning. It surely confused the compiler, making it completely lose track of the type of other, unrelated variables.

There is a good explanation here: http://stackoverflow.com/questions/2528 ... value-in-c