Re: weird problem

Alef.Veld@xxxxxxxxx wrote:

On Jan 24, 7:51 pm, j...@xxxxxxxxxxx (Jens Thoms Toerring) wrote:

Yes they are the same. objects is a typedef for a struct like:

typedef struct objects {
char *x;
char *y;
char *z;
} objects;

Obviously plus a few missing members like prev, next and hostname;-)

{
objects *search = o_head;
What's 'o_head'?

o_head is a objects pointer pointing to the first node in the linked
list i'm using.

Well, you don't show us anything about this linked list and what
'tmp' has for a relation to it - 'tmp' could point to an element
of this list or to something completely different. All I can do
make guesses, e.g. that for some unknown reason you assume that
'tmp' magically becomes identical to 'o_tail'.

if ((tmp->x = malloc(sizeof(float) + 7)) == NULL)

perror("malloc");
Using perror() here is useless since malloc() doesn't set set errno if
it fails to obtain as much memory as requested. perror() is meant to
print out a human-readable string for what errno is set to. And if
there's nothing that woul have set errno what it prints out is com-
pletely bogus.


Hmm, yes kind of a shame malloc doesn;t use errno. I use perror because
i want to do consistent error reporting so i use it with every error,
if errno is used or not.

Well, malloc() doesn't do that, so you've got to deal with it;-)

exit(1);
}
snprintf(o_tail->x, sizeof(float) + 7, "%.0f",
((grid_size - grid_start) * rand()) / RAND_MAX +
grid_start);
Where is 'o_tail' defined? Are you sure you don't intend to write into
the string 'tmp->x' you just allocated before? And where are 'grid_start'
and 'grid_size' defined what what type do the have? Are they floats or
doubles or something else?

o_tail is a global pointing to the last node in the linked list. I'm
not sure you mean by 'i don't intend to write into
the string tmp->x you just allocated before'. I want to write into the
string, i just freed them remember?

What did you just free()? On the contrary, you just _allocated_
memory for 'tmp->x'. And now you don't write into that shiny new
memory you just got but somewhere else, i.e. to what 'o_tail->x'
points to. And there is nothing to be seen that would indicate
that 'o_head->x' and 'tmp->x' are identical (that would probably
require that 'o_head' is identical to 'tmp', but there's nothing
that would clearly show that this is the case, it rather looks
like this isn't true)..

And worse, sometime later you use strcmp() on 'tmp->x', even
though you never initialized the memory 'tmp->x' is pointing
to. And since strcmp() isn't save to be used with uninitialized
memory this is badly broken.

grid_start and grid_size are floats. they are set in the beginning of
the program to -10 and grid_size is calculated dynamically, depending
on how many objects there are.

/* Check for possible collision */
while (search != NULL) {
if (collisions > 0 &&
collisions ==
((grid_size - grid_start) * (grid_size - grid_start))) {Where is 'collisions' defined and what type does it have? Looks like an
integer counter, but you seem to compare it to some float or double value,
which, if these assumptions should be true, is rather dubious to say the
least. But since I have no idea what it's meant to test I can't make any
suggestions on how to correct it.

collisions is int and defined as a global (and declared extern) . It is
only reset when the grid_size is increased, otherwise it is incremented
for every collision it matches.

So I am lead to assume that '(grid_size - grid_start)' is the size of
a square grid and you want to compare the number of points on that
grid to the number of 'collisions'. In that case you need to round
the result of squaring the grid size to the nearest int, otherwise
you have a good chance that the comparison will never be true -
floating point numbers aren't necessarily exact, if grid_size is e.g.
5,0 and grid_start is -7.0, then the result of squaring the differ-
rence could easily be e.g. 143.999999999998, which is not equal to
144.

if (tmp != search &&
!strcmp(tmp->x, search->x) &&

Look, here you suddenly use 'tmp->x' as if it would be pointing to
a string. But actually it points to uninitialized memory. Let's
hope that at least 'search->x' points to a real string;-)

How do you deter-
mine that tmp->x or tmp->y or tmp->z are NULL? And since you don't
show what 'search' is and how it got set up there's no way someone
could figure out what's going wrong.

search is just a tmp pointer set to the 'head' of the list. I don't
understand
why i would want to test x y and z for NULL.

Me neiter. It was you who wrote:

But, when going in the search loop,
apparently tmp->x y and z and search->x,y,z are not valid anymore
because they are both NULL so it seems.

I was just asking how you came to that conclusion.

I free them before i dive into assign_coordinate, and allocate them
right back after. So they are always allocated. The other pointers
search encounters, are not yet freed and still valid.

That's exactly my point. You assign to the 'x', 'y' and 'z' members
of 'tmp' and make sure they are not NULL and you don't touch the
members of 'search', so, assuming they weren't NULL to start with,
they shouldn't suddenly be set NULL. All I asked was how you came
up with the idea that they would be NULL despite this;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.

Relevant Pages

  • Re: using structs like BROWSEINFO and OPENFILENAME (string members)
    ... Private Type BROWSEINFO ... pszDisplayName As String ... > ...notice the data type change for the two string members. ... > memory at lpTitle and the data is ansi, so somehow vb figured out to use ...
    (microsoft.public.vb.winapi)
  • Locally allocated string thrown in exception mystery
    ... CDException is a subclass of runtime_error whose constructor takes a const ... string& parameter. ... As tmp is locally scoped, memory is allocated on the stack. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: GC with lots of small ones
    ... and other objects are members in long existing containers most of my points ... It eats too much memory - log files exceeding 100MB ... and that object (in your case a string) will ...
    (microsoft.public.dotnet.general)
  • Re: Fast string operations
    ... Looping: I thought looping over arrays in managed code was "slow" ... array handling and such. ... The problem with TrimHelper is that it always returns a new string instance. ... The customer perceives this as a memory leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)