Thread: Unkown Hang

Replace the fopen call with a malloc call. Allocate a few megs of memory, and see if it makes it hang. If it doesn't, call free.

You might also consider opening your log file ahead of time, and just leaving it open for the duration of the program.


Quzah.

Originally Posted by abraham2119

I do not know. I was simply clarifying the apparent doubt on whether fopen() used malloc().

gotcha!
no worries, got confused with your post, so thanks for clarifying

Originally Posted by abraham2119

That should not be his solution. He should fix the problem.

Of course! I suggested this naive technique in favor of using a debugger, because if malloc() fails, then the heap was most likely already trashed before that call. A debugger won't help much here. Simply allocating enough memory may give proof to the assumption that the hang is indeed caused by malloc().

And I thought that fopen() calling malloc() was a definite; what brings doubts? It is returning a FILE*, so obviously, it cannot return a local variable, rather it allocates the memory on the heap, using, of course, malloc().

What brings doubt is the fact that I didn't write malloc(). My manpages states that the "fopen(), fdopen() and freopen() functions may also fail and set errno for any of the errors specified for the routine malloc(3)", which doesn't imply that they are actually calling malloc() (or allocating memory at all). Imagine fopen() re-implementing the malloc() functionality, or having a fixed size buffer large enough to hold the maximum number of open FILEs. This may seem stupid, but I didn't want to make premature assumptions about the true nature of fopen().

Greets,
Philip

Originally Posted by Bladactania

So are you suggesting that I replace the fopen() with (FILE *) malloc(5000); and see what happens then?

No, I'm suggesting to replace every malloc(<expression>) in your code with malloc(<some constant value that is guaranteed to be large enough to hold whatever you want to store there, e.g. 1MB of memory>).

In my opinion, the hang is caused by a trashed heap due to allocating less memory than is actually needed. In order to give evidence to this assumption, it's a good idea to check whether the hang disappears if you simply allocate enough memory. The problem with a trashed heap is that strange behavior may occur only after the next call to malloc(), which may be perfectly fine in itself (which I suppose fopen()'s malloc() to be).

Greets,
Philip

Originally Posted by Snafuist

No, I'm suggesting to replace every malloc(<expression>) in your code with malloc(<some constant value that is guaranteed to be large enough to hold whatever you want to store there, e.g. 1MB of memory>).

In my opinion, the hang is caused by a trashed heap due to allocating less memory than is actually needed. In order to give evidence to this assumption, it's a good idea to check whether the hang disappears if you simply allocate enough memory. The problem with a trashed heap is that strange behavior may occur only after the next call to malloc(), which may be perfectly fine in itself (which I suppose fopen()'s malloc() to be).

Greets,
Philip

Quite often, replacing "malloc(x)" with "malloc(5*x)" will show that it's this type of problem, as Philip says.

Since this is (or at least appears to be) DOS, I expect allocating 1MB may not work very well.

--
Mats

Ok, now I've actually been reading your code and I think I know what causes the hang:

Code:

  char *sTemp = (char*) malloc((sizeof(char) * strlen(s1)) + (sizeof(char) * strlen(s2)));

  strcpy(sTemp, s1);
  strcat(sTemp, s2);

You need to allocate one more byte for the terminating '\0' or else strcat() will write to memory that hasn't been allocated previously:

Code:

  char *sTemp = malloc(strlen(s1) + strlen(s2) + 1);

Note that sizeof(char) == 1 and that you don't need to cast void* in assignments, which makes it slightly more readable.

Greets,
Philip

Casting malloc is NOT good practice in my view - malloc returns a void pointer, which can be converted to any other pointer without a cast [in C, rules are different in C++]. If you cast it, you will not see that you've forgot to include <stdilib.h> which provides the prototype for malloc. If we then have one of those ABI's where a pointer is returned in a different register than integer values, the compiler will actually generate code that uses the wrong register.

sizeof(char) is GUARANTEED to be 1. Multiplying by 1 is pointless.

--
Mats

Originally Posted by itCbitC

What platform are you working on? IMO the OS should be able to catch this exception at runtime and abend the program with a segv.

It is DOS (or something close to DOS), I'm 99% sure of that - and it doesn't have memory protection, so no segv.

--
Mats