Re: weird problem



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

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

Well, yes, the struct has somewhat more members but i didn't want to
bore you with those. They are not relevant in any case.

{
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'.

When i want to move through my list, i always declare a tmp *ptr, and
assign that either to the head or the tail of the list, or sometimes a
node somewhere specific.


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'.

Hmm, maybe i wasn't clear. Before i call assign_coordinate and malloc
memory to x y and z, i free
them (outside of assign_coordinate). In my first post i mentioned:
--
So i first free the pointers x,y,z like so:
while(tmp!=NULL) {
free(tmp->x);
free(tmp->y);
free(tmp->z);
Then call assign_coordinate:
assign_coordinate(tmp); (Note that tmp itself is NOT free, only
x,y,z
pointers)
and so on:
tmp=tmp->next;}
--
So i freed those x y and z pointers in tmp.

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)..

Sorry my fault, i did not supply you with enough code. What i am doing
is that after i resize my grid (or rather decrease), there is a fat
chance that my previous coordinates are not correct anymore. So i free
all my x, y and z pointers, as show previously, and call
assign_coordinate to create new ones, randomly. Then i search through
my existing list if there is a possible collision. Remember, i did not
yet free the other ones, only the first one. When this one gets new
coordinates, tmp goes to tmp->next, then calls free() again, etc.




..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,

You're right. This might actually be my problem then. Would a cast
suffice or do i have to manually
round this off somehow with a conversion specifier.
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.


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.

see my answer below :-)
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:

I don't test them for NULL because i do not search the same ptr i'm
supplying (which x ,y,z are freed) (although i did not specifically set
it to NULL i assuming it's valid because i allocated memory in
assign_coordinate.



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;-)

Ah. I see that without proper code this is getting confusing for the
both of us :-). I will see if i can supply both 2 functions which cause
my troubles.

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

Many thanks,
-alef

.

Relevant Pages

  • Re: Using sparse to catch invalid RCU dereferences?
    ... RCU-protected pointers directly, and all of these would need to be ... in to gcc than I am could probably pull it off. ... // no warnings from sparse due to forced cast ... rcu_assign_pointer(prot, tmp); ...
    (Linux-Kernel)
  • Re: can the member function be compared?
    ... legal if both `Func1' and `Func2' are within the same access ... If two pointers point to nonstatic data members of the ... 5.9/1 The operands shall have arithmetic, enumeration or pointer type. ...
    (microsoft.public.vc.language)
  • Re: can the member function be compared?
    ... void Func1() ... If two pointers point to nonstatic data members of the ... 5.9/1 The operands shall have arithmetic, enumeration or pointer type. ...
    (microsoft.public.vc.language)
  • Re: Spacing in derived data types, using SEQUENCE attribute, for MPI
    ... Does not guarantee against padding, ... 6.5.8p5 When two pointers are compared [that constraints allow to be ... pointers to structure members declared later compare greater than ... I have heard of no C++ compiler that doesn't keep it for ALL structs ...
    (comp.lang.fortran)
  • Re: Using sparse to catch invalid RCU dereferences?
    ... RCU-protected pointers directly, and all of these would need to be ... in to gcc than I am could probably pull it off. ... // no warnings from sparse due to forced cast ... rcu_assign_pointer(prot, tmp); ...
    (Linux-Kernel)