malloc's strang behavior
 

Hi all

I'm writting a simple code to solve an ACM problem
(http://acm.uva.es, it is the problem #468). In its code I have the
following fragment:

freq = calcfreq(hashfreq, strfreq, input);
printf("before malloc: %s (%p)\n", input+INPUTLEN);
hchars = (char *)malloc(freq*sizeof(char));
schars = (char *)malloc(freq*sizeof(char));
printf("after malloc: %s\n (%p)\n", input+INPUTLEN);

Since input has nothing to do with the mallocs I expected it would be
unchanged but this isn't happening. Suppouse input points to the
string "xxxxyy", this fragment of code outputs like this:

before malloc: xxxxyy (0x8049ef0)
after malloc: xxxx (0x8049ef0)

Anyone got a clue on what could be happening here?


Thanks in advance

--
Gustavo G. Rondina
http://gustgr.freeshell.org

Re: malloc's strang behavior
 

Gustavo G. Rondina <gustgr@brlivre.org> writes:
> Hi all
>
> I'm writting a simple code to solve an ACM problem
> (http://acm.uva.es, it is the problem #468). In its code I have the
> following fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("before malloc: %s (%p)\n", input+INPUTLEN);
> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("after malloc: %s\n (%p)\n", input+INPUTLEN);
>
> Since input has nothing to do with the mallocs I expected it would be
> unchanged but this isn't happening. Suppouse input points to the
> string "xxxxyy", this fragment of code outputs like this:
>
> before malloc: xxxxyy (0x8049ef0)
> after malloc: xxxx (0x8049ef0)
>
> Anyone got a clue on what could be happening here?

In both printf calls, the format string has a "%s" and a "%p"
conversion, but you only provide one addtional argument rather than
two. I wouldn't necessarily expect this to cause the specific problem
you're seeing, but you should definitely fix it before attempting to
proceed any further.

Casting the result of malloc() is unnecessary, and can mask errors
such as forgetting the "#include <stdlib.h>". Also sizeof(char) is
always 1, by definition. Thus the two assignments can be simplified
to

hchars = malloc(freq);
schars = malloc(freq);

Finally, if you still have questions after making these changes,
please show us a small, complete, compilable program that exhibits the
problem. We can't see the declarations of your variables, and we
can't tell whether you've included the proper headers. That makes it
difficult to help you. (And there's a fairly good chance that you'll
solve the problem yourself while paring it down to something small
enough to post.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Re: malloc's strang behavior
 

On 21 Jul 2004 00:52:54 GMT, Gustavo G. Rondina <gustgr@brlivre.org>
wrote:

>Hi all
>
> I'm writting a simple code to solve an ACM problem
>(http://acm.uva.es, it is the problem #468). In its code I have the
>following fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("before malloc: %s (%p)\n", input+INPUTLEN);
> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("after malloc: %s\n (%p)\n", input+INPUTLEN);
>
> Since input has nothing to do with the mallocs I expected it would be
>unchanged but this isn't happening. Suppouse input points to the
>string "xxxxyy", this fragment of code outputs like this:
>
> before malloc: xxxxyy (0x8049ef0)
> after malloc: xxxx (0x8049ef0)
>
> Anyone got a clue on what could be happening here?
>
>
>Thanks in advance

I give up. How do you get two variables formatted in your output (to
match the two format specifiers) when you have only one argument
following the format string?

Why are you casting the return from malloc? If it is to silence a
compiler diagnostic about converting int to char* then you have
invoked undefined behavior by not providing the prototype for malloc.
If it is to silence a compiler diagnostic about converting void* to
int* then you are compiling it as C++ and this is the wrong group.

Since sizeof(char) is always 1, you can remove that expression from
the arguments to malloc.

Can you provide a compilable example that exhibits the behavior?


<<Remove the del for email>>

Re: malloc's strang behavior
 

Sorry guys, copy and paste problem. Here is the correct code fragment:

freq = calcfreq(hashfreq, strfreq, input);
printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);
hchars = (char *)malloc(freq*sizeof(char));
schars = (char *)malloc(freq*sizeof(char));
printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);

The problem it is still there. The output follows:

before malloc: xxxxyy (0x8049ef0)
after malloc: xxxx (0x8049ef0)

The full code is avaliable at: http://www.brlivre.org/c/468.c

If anyone have spare time I would appreciate some help.


Thanks,
Gustavo

PS. this is not any kind of homework, I code (at least I try to) as a
hobby.

Re: malloc's strang behavior
 

Sorry about the mess, here is the _right_ code:

http://www.brlivre.org/c/468.c

This code isn't finished yet, I'll try to fix this problem before
going on. The problem seems to be on this code fragment:

freq = calcfreq(hashfreq, strfreq, input);
printf("before malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);
hchars = (char *)malloc(freq*sizeof(char));
schars = (char *)malloc(freq*sizeof(char));
printf("after malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);

Here is what I got:

$ ./468
1

aaaaab
xxxxxxyyy
before malloc: xxxxxxyyy (0x8049f00)
after malloc: xxxx (0x8049f00)
$

Anyone got a clue?


Thanks (again)


--
Gustavo G. Rondina
http://gustgr.freeshell.org

Re: malloc's strang behavior
 

Gustavo G. Rondina wrote:
> Hi all
>
> I'm writting a simple code to solve an ACM problem
> (http://acm.uva.es, it is the problem #468). In its code I have the
> following fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);

We don't know, of course, what any of freq, calcfreqm hashfreq, (badly
named) strfreq, or input are.

> printf("before malloc: %s (%p)\n", input+INPUTLEN);

This is nonsense. The specification string expects two more arguments
(for three in all). You give only one more. Luckily for you, we can't
tell if you forgot to cast the argument corresponding to "%p" to
(void *).

> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));

At this point we know for sure you have not followed normal usenet
etiquette and lurked before posting, or checked the archives, or checked
the FAQ. You would do better with
hchars = malloc(freq);
schars = malloc(freq);
or
hchars = malloc(freq * sizeof *hchars);
schars = malloc(freq * sizeof *schars);
Of course you should #include <stdlib.h> and check the returned values
from malloc for success.

> printf("after malloc: %s\n (%p)\n", input+INPUTLEN);

This is nonsense, again.

> Since input has nothing to do with the mallocs I expected it would be
> unchanged but this isn't happening. Suppouse input points to the
> string "xxxxyy", this fragment of code outputs like this:
>
> before malloc: xxxxyy (0x8049ef0)
> after malloc: xxxx (0x8049ef0)
>
> Anyone got a clue on what could be happening here?

It appears that the array which either is 'input' or is pointed to by
'input' has a size of 4 and was initialized incorrectly, perhaps with
char input[4]="xxxx";
Somehow you have gained a '\0' in the first char _following_ input in
the process of allocating space.

All this is guessing, since you have not not posted compilable code, but
have posted something that is *not* your real code, else the output
would not be what you claim.

Re: malloc's strang behavior
 

Gustavo G. Rondina wrote:

> Sorry guys, copy and paste problem. Here is the correct code fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);
^^^^^^^^^^^^^^
This is almost certainly wrong. Provide the cast (void *) to the type
%p expects.

> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);
>
> The problem it is still there. The output follows:
>
> before malloc: xxxxyy (0x8049ef0)
> after malloc: xxxx (0x8049ef0)
>
> The full code is avaliable at: http://www.brlivre.org/c/468.c
>

Come on: do the small amount of work necessary to produce a compilable
minimal program that exhibits your problem. If it's too much trouble
for you to do that, it's too much trouble for us. Post the resulting
code here. No one here has reason to go clicking on wesites we have no
reason to trust.

Re: malloc's strang behavior
 

On 21 Jul 2004 01:48:28 GMT, Gustavo G. Rondina <gustgr@brlivre.org>
wrote:

>Sorry guys, copy and paste problem. Here is the correct code fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);
> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("%s (%p)\n", input+INPUTLEN, input+INPUTLEN);
>
>The problem it is still there. The output follows:
>
> before malloc: xxxxyy (0x8049ef0)
> after malloc: xxxx (0x8049ef0)
>
>The full code is avaliable at: http://www.brlivre.org/c/468.c
>
>If anyone have spare time I would appreciate some help.
>
>

Your readinput function invokes undefined behavior. It attempts to
read twice as many strings as you allocate space for.

Your calcfreq function will invoke undefined behavior if any of your
input contains anything other than lowercase ASCII characters since
your offset into the arrays will be negative.

The readinput error can very easily break your run-time memory
management and cause subsequent calls to malloc to do very strange
things.


<<Remove the del for email>>

Re: malloc's strang behavior
 

Gustavo G. Rondina wrote:

> Sorry about the mess, here is the _right_ code:
>
> http://www.brlivre.org/c/468.c
>
> This code isn't finished yet, I'll try to fix this problem before
> going on. The problem seems to be on this code fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("before malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);
> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("after malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);

No, the problem is that you've written past the end of `input`
somewhere, since if you mallocate an extra 1000 bytes for it,
the problem goes away.

Given that the code is horribly opaque (eg why on Earth do you write
`*(E+F)` for `E[F]`, what is 97 when it's a home, what it is all *for*?),
motivation for proceeding further in the analysis escapes me.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

Re: malloc's strang behavior
 

Gustavo G. Rondina <gustgr@brlivre.org> wrote in message news:<2m62jpFiugbuU2@uni-berlin.de>...
> Sorry about the mess, here is the _right_ code:
>
> http://www.brlivre.org/c/468.c
>
> This code isn't finished yet, I'll try to fix this problem before
> going on. The problem seems to be on this code fragment:
>
> freq = calcfreq(hashfreq, strfreq, input);
> printf("before malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);
> hchars = (char *)malloc(freq*sizeof(char));
> schars = (char *)malloc(freq*sizeof(char));
> printf("after malloc: %s (%p)\n", input+INPUTLEN, input+INPUTLEN);
>
> Here is what I got:
>
> $ ./468
> 1
>
> aaaaab
> xxxxxxyyy
> before malloc: xxxxxxyyy (0x8049f00)
> after malloc: xxxx (0x8049f00)
> $
>
> Anyone got a clue?
>
>
> Thanks (again)


The most likely explanation is that you have corrupted memory
elsewhere in your program, and you are only seeing the result here.
For instance if the storage pointed to by "input" has already being
freed.