WANTED: Removing all elements matching a particular key from a Queue
WHAT I GOT: Segfault
WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too complex to be understood. removeAllMatches(arg1, arg2) is supposed to remove all elements from arg1 which match value of arg2.
On Tuesday, May 8, 2012 9:09:39 AM UTC+1, arnuld wrote:
> WANTED: Removing all elements matching a particular key from a Queue
> WHAT I GOT: Segfault
> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too > complex to be understood. removeAllMatches(arg1, arg2) is supposed to > remove all elements from arg1 which match value of arg2.
I don't get any output at all it crashes at the first printQueue() call in main(). The Head and Tail pointers contain crap (0xcdcdcd on a Microsoft system). They contain crap because newQueue() doesn't initialise them.
Why didn't you use a debugger? That's how I found the bug.
> On Tuesday, May 8, 2012 9:09:39 AM UTC+1, arnuld wrote:
>> WANTED: Removing all elements matching a particular key from a Queue
>> WHAT I GOT: Segfault
>> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too
>> complex to be understood. removeAllMatches(arg1, arg2) is supposed to
>> remove all elements from arg1 which match value of arg2.
> I don't get any output at all it crashes at the first printQueue() call in > main(). The Head and Tail pointers contain crap (0xcdcdcd on a Microsoft > system). They contain crap because newQueue() doesn't initialise them.
> Why didn't you use a debugger? That's how I found the bug.
Mine just prints forever on printQueue(). Looking at newQueue() instantly reveals the problem.
No need for any debugger. And what exactly did it say anyway?
> WANTED: Removing all elements matching a particular key from a Queue
> WHAT I GOT: Segfault
> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too
> complex to be understood. removeAllMatches(arg1, arg2) is supposed to
> remove all elements from arg1 which match value of arg2.
I don't know what's wrong with your code (though I have strong
suspicions about the code which tries to do some special casing for
start and end of list), but if I could be bothered to investigate I'd
probably do the old "paper computer" exercise...
On a largish sheet of paper I'd draw the structure of my linked list
at the point that the removeAll function was invoked, with a box
representing each entry of the list, with the forward and back
pointers and the value stored.
I'd then draw boxes for p, d and h (horrid names for variables) and
walk through the code updating all the boxes as I went.
I don't know why you keep repeating your checking code rather than
extracting it to a "sanity_check" function. I also don't know why you
don't have a function for "remove the current entry" from the list,
but you seem to be making a big deal out of a fairly small exercise.
another
BUG:
you free() the memory pointed to by d (which is the same as h),
and in the for statement you access it: h = h->next
retrieve the next pointer _before_ you free() the element.
perhaps you should use some library for that...
glib or glibc's <search.h> perhaps...
> On Tue, 08 May 2012 08:01:26 -0400, Eric Sosman wrote:
>> On 5/8/2012 4:09 AM, arnuld wrote:
> I've only skimmed your code, but this bit is obviously wrong:
>> struct myQueue* newQueue(void)
>> {
>> struct myQueue* p = malloc(1 * sizeof *p); if(NULL == p)
>> {
>> printf("Out of Memory\n");
>> exit(EXIT_FAILURE);
>> }
>> return p;
>> }
> Hint: What are the values of the elements in the newly-allocated
> struct?
One needs to keep on practicing writing code and thinking about data structures, else he forgets (like me). (Now, taking dequeue code from other poster), is this fine now or still some bits are wrong:
int queue_sanity_check(struct myQueue* q)
{
int ret = CODE_ERR; if(NULL == q)
{
printf("Invalid Args\n");
ret = CODE_ERR;
}
else if(NULL == q->head && NULL == q->tail)
{
printf("Queue is already empty\n");
ret = CODE_SUCC;
}
else if(NULL == q->head || NULL == q->tail)
{
printf("IN: %s @%d; ", __func__, __LINE__);
printf("There is something seriously wrong with head/tail assignment of your Queue\n");
exit(EXIT_FAILURE);
}
else
{
ret = CODE_SUCC;
}
return ret;
}
================ OUTPUT =====================
/home/arnuld/programs/C $ gcc -ansi -pedantic -Wall -Wextra Queue.c /home/arnuld/programs/C $ ./a.out -----------------------------------------
Queue is already empty
Empty Queue, Adding first element
Adding Element to tail
Adding Element to tail
Adding Element to tail
Adding Element to tail
Adding Element to tail
Adding Element to tail
title: -1
title: 100
title: 38
title: 100
title: 38
title: 9
title: 100
-----------------------------------------
title: -1
title: 38
title: 38
title: 9
-----------------------------------------
/home/arnuld/programs/C $
>One needs to keep on practicing writing code and thinking about data >structures, else he forgets (like me). (Now, taking dequeue code from >other poster), is this fine now or still some bits are wrong:
> {
> printf("IN: %s @%d; ", __func__, __LINE__);
> printf("There is something seriously wrong with head/tail >assignment of your Queue\n");
> exit(EXIT_FAILURE);
> }
> else
> {
> ret = CODE_SUCC;
> }
> return ret;
>}
>================ OUTPUT =====================
>/home/arnuld/programs/C $ gcc -ansi -pedantic -Wall -Wextra Queue.c >/home/arnuld/programs/C $ ./a.out >-----------------------------------------
>Queue is already empty
>Empty Queue, Adding first element
>Adding Element to tail
>Adding Element to tail
>Adding Element to tail
>Adding Element to tail
>Adding Element to tail
>Adding Element to tail
>title: -1
>title: 100
>title: 38
>title: 100
>title: 38
>title: 9
>title: 100
>-----------------------------------------
>title: -1
>title: 38
>title: 38
>title: 9
This demonstrates you don't use q->tail so why bother maintaining it?
> >> WANTED: Removing all elements matching a particular key from a Queue
> >> WHAT I GOT: Segfault
> >> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too
> >> complex to be understood. removeAllMatches(arg1, arg2) is supposed to
> >> remove all elements from arg1 which match value of arg2.
> > I don't get any output at all it crashes at the first printQueue() call in > > main(). The Head and Tail pointers contain crap (0xcdcdcd on a Microsoft > > system). They contain crap because newQueue() doesn't initialise them.
> > Why didn't you use a debugger? That's how I found the bug.
> Mine just prints forever on printQueue(). Looking at newQueue() instantly > reveals the problem.
and main()
> No need for any debugger. And what exactly did it say anyway?
well the program has Undefined Behaviour so the question isn't really meaningful. Visual C++ gives:-
"Unhandled exception at 0x00411cc9 in quick.exe: 0xC0000005: Access violation reading location 0xcdcdcdcd."
The debugger shows it crashed in printStruct() and p has an insane value.
> >> WANTED: Removing all elements matching a particular key from a Queue
> >> WHAT I GOT: Segfault
> >> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too
> >> complex to be understood. removeAllMatches(arg1, arg2) is supposed to
> >> remove all elements from arg1 which match value of arg2.
> > I don't get any output at all it crashes at the first printQueue() call in > > main(). The Head and Tail pointers contain crap (0xcdcdcd on a Microsoft > > system). They contain crap because newQueue() doesn't initialise them.
> > Why didn't you use a debugger? That's how I found the bug.
> Mine just prints forever on printQueue(). Looking at newQueue() instantly > reveals the problem.
and main()
> No need for any debugger. And what exactly did it say anyway?
well the program has Undefined Behaviour so the question isn't really meaningful. Visual C++ gives:-
"Unhandled exception at 0x00411cc9 in quick.exe: 0xC0000005: Access violation reading location 0xcdcdcdcd."
The debugger shows it crashed in printStruct() and p has an insane value.
> On Tue, 08 May 2012 23:21:06 -0700, Barry Schwarz wrote:
>> On 09 May 2012 05:43:02 GMT, arnuld <sunr...@invalid.address> wrote:
> ret is already initialized to CODE_ERR.
I know. I learned from someone here that assignment at initialization of a variable is always a good idea. I see it solves problems for me (in case of int types)
>> struct myStruct* h;
>> h = q->head;
>> q->head = q->head->next;
> If q->head is NULL (the queue is empty), this invokes undefined
> behavior.
I have removed this in code I posted 2nd time.
>> free(h);
>> if(NULL == q->head)
>> {
>> printf("Removing Last element left\n"); q->head = q->tail = > NULL;
> You already know q->head is NULL.
yeah. So, instead of s->head = s->tail = NULL, I could have used s->tail = s->head. It was just a matter of style for me.
> Assume the queue consists of nodes containing 2, 1, 3, 1 and num is 1.
>> for(current = q->head; current; current = current->next)
> Whenever you free current in the loop, the third expression above
> invokes undefined behavior on the next iteration.
>> {
>> if(num == current->num)
> During iteration 1, this is false.
> During iteration 2, this is true.
> During iteration 3, this is false.
> During iteration 4, this is true.
> ..SNIP... LOTS OF CODE
> On Tuesday, May 8, 2012 2:03:48 PM UTC+1, Bart wrote:
>> <nick_keighley_nos...@hotmail.com> wrote in message
>> > Why didn't you use a debugger? That's how I found the bug.
>> Mine just prints forever on printQueue(). Looking at newQueue() instantly
>> reveals the problem.
> and main()
>> No need for any debugger. And what exactly did it say anyway?
> well the program has Undefined Behaviour so the question isn't really
> meaningful. Visual C++ gives:-
> "Unhandled exception at 0x00411cc9 in quick.exe: 0xC0000005: Access
> violation reading location 0xcdcdcdcd."
> The debugger shows it crashed in printStruct() and p has an insane value.
As I said, when I tried it under one compiler, it just looped forever
p;rinting the same sequence of 3 or 4 values, so p (ie. q->head) presumably
had a sensible enough value.
Debuggers have their uses but are probably overkill for an obvious logic error within the first dozen lines of execution!
When a program goes wrong a few billion statements from the start, because
of some unrelated code a billion or two statements back in a totally
different part, then it might be time to wheel it out (and even then I'm not
sure how they could help).
> On Tue, 08 May 2012 05:09:09 -0700, nick_keighley_nospam wrote:
> ..SNIP...
> you could tidy things up by factoring out your queue check code that
> appears in at least three places
you are right. I did that and now after reading the analysis from Barry Schwarz I can see that head/tail pointing at wrong places, so I should make a check for that too ?
No, unlike earlier now I think those checks will not save these programming errors I am making. I better set pointers right rather than spending my typing-energy to avoid/find errors.
On Wednesday, May 9, 2012 10:37:38 AM UTC+1, Bart wrote:
> <nick_keighley_nos...@hotmail.com> wrote in message
> news:17230148.361.1336546987566.JavaMail.geo-discussion-forums@vbcm9...
> > On Tuesday, May 8, 2012 2:03:48 PM UTC+1, Bart wrote:
> >> <nick_keighley_nos...@hotmail.com> wrote in message
> >> > Why didn't you use a debugger? That's how I found the bug.
> >> No need for any debugger. And what exactly did it say anyway?
> > well the program has Undefined Behaviour so the question isn't really
> > meaningful. Visual C++ gives:-
> > "Unhandled exception at 0x00411cc9 in quick.exe: 0xC0000005: Access
> > violation reading location 0xcdcdcdcd."
> > The debugger shows it crashed in printStruct() and p has an insane value.
> As I said, when I tried it under one compiler, it just looped forever
> p;rinting the same sequence of 3 or 4 values, so p (ie. q->head) presumably
> had a sensible enough value.
> Debuggers have their uses but are probably overkill for an obvious logic > error within the first dozen lines of execution!
and how would I know the crash was going to occur within a few dozen lines of startup?
> When a program goes wrong a few billion statements from the start, because
> of some unrelated code a billion or two statements back in a totally
> different part, then it might be time to wheel it out (and even then I'm not
> sure how they could help).
whatever. I judged running under a debugger was a quicker way to find the bug than ploughing through lots of source code. It so happened it pin-pointed the bug almost instantly.
>> On Tue, 08 May 2012 23:21:06 -0700, Barry Schwarz wrote:
>>> On 09 May 2012 05:43:02 GMT, arnuld <sunr...@invalid.address> wrote:
>> ret is already initialized to CODE_ERR.
> I know. I learned from someone here that assignment at initialization of > a variable is always a good idea. I see it solves problems for me (in > case of int types)
I disagree, but that's a controversial opinion, and I won't bother
arguing it again. However, since you've already initialized it to
CODE_ERR, there's no need to set it to that value a second time.
...
>>> if(NULL == q->head)
>>> {
>>> printf("Removing Last element left\n"); q->head = q->tail = >> NULL;
>> You already know q->head is NULL.
> yeah. So, instead of s->head = s->tail = NULL, I could have used s->tail > = s->head. It was just a matter of style for me.
or s->tail = NULL, which is even simpler.
-- James Kuyper
> On Tue, 08 May 2012 23:21:06 -0700, Barry Schwarz wrote:
>> On 09 May 2012 05:43:02 GMT, arnuld <sunr...@invalid.address> wrote:
>> p = malloc(1 * sizeof *p);
> What is the point of multiplying by 1?
Because it makes me remember that malloc() takes number of elements. It sounds strange but I do forget to add number of elements most of the times.
> Assume the queue consists of nodes containing 2, 1, 3, 1 and num is 1.
>> for(current = q->head; current; current = current->next)
> Whenever you free current in the loop, the third expression above
> invokes undefined behavior on the next iteration.
It did not. Now I know why. After free(current), current may be pointing to garbage. That's why the practice of setting the pointer to NULL after free() was created.
Oddly, code worked fine all the time on my machine producing correct results for 8 hours. Just now it Segfaulted.
> q->tail now points to node containing 2 which is same as q->head. Your q
> is now broken.
It is broke, Still trying to figure out how to write it correctly.
> I think the if test should be on the pointers, not on num:
> if (current = q->tail)
aah... pointers do compare equal like int (you meant current == q->tail)
> Since you have managed to create the situation, you might also want to
> add the following to the end of the if:
> || q->tail->next != NULL
I understood my mistake. Like I said, I did the analysis after reading your analysis I can see that head/tail pointing at wrong places, so I should make a check for that too ? No, unlike earlier now I think those checks will not save these programming errors I am making. I better set pointers right rather than spending my typing-energy to avoid/find errors.
> This demonstrates you don't use q->tail so why bother maintaining it?
q->tail to add, q->head to remove. Thats the purpose.
On 09 May 2012 13:18:08 GMT, arnuld <sunr...@invalid.address> wrote:
>> On Tue, 08 May 2012 23:21:06 -0700, Barry Schwarz wrote:
>>> On 09 May 2012 05:43:02 GMT, arnuld <sunr...@invalid.address> wrote:
>>> p = malloc(1 * sizeof *p);
>> What is the point of multiplying by 1?
>Because it makes me remember that malloc() takes number of elements. It >sounds strange but I do forget to add number of elements most of the >times.
Better to remember something true. malloc takes number of bytes.
calloc takes number of elements and number of bytes per element but
involves extra overhead which is not needed here.
>> Assume the queue consists of nodes containing 2, 1, 3, 1 and num is 1.
>>> for(current = q->head; current; current = current->next)
>> Whenever you free current in the loop, the third expression above
>> invokes undefined behavior on the next iteration.
>It did not. Now I know why. After free(current), current may be pointing >to garbage. That's why the practice of setting the pointer to NULL after >free() was created.
After free(current), current is indeterminate and doesn't point
anywhere. Whether or not you set current to NULL after the free, any
attempt to dereference current, as in the expression current->next,
invokes undefined behavior.
>Oddly, code worked fine all the time on my machine producing correct >results for 8 hours. Just now it Segfaulted.
Consider yourself lucky. Frequently undefined behavior waits until an
important customer is present for the demo.
>> q->tail now points to node containing 2 which is same as q->head. Your q
>> is now broken.
>It is broke, Still trying to figure out how to write it correctly.
>> I think the if test should be on the pointers, not on num:
>> if (current = q->tail)
>aah... pointers do compare equal like int >(you meant current == q->tail)
Yes, I make this mistake more often than I care to admit.
>> Since you have managed to create the situation, you might also want to
>> add the following to the end of the if:
>> || q->tail->next != NULL
>I understood my mistake. Like I said, I did the analysis after reading >your analysis I can see that head/tail pointing at wrong places, so I >should make a check for that too ? No, unlike earlier now I think those >checks will not save these programming errors I am making. I better set >pointers right rather than spending my typing-energy to avoid/find errors.
>> This demonstrates you don't use q->tail so why bother maintaining it?
>q->tail to add, q->head to remove. Thats the purpose.
> On May 9, 10:59 pm, Barry Schwarz <schwa...@dqel.com> wrote:
>> On 09 May 2012 13:18:08 GMT, arnuld <sunr...@invalid.address> wrote:
>>Because it makes me remember that malloc() takes number of elements. It
>>sounds strange but I do forget to add number of elements most of the
>>times.
> Better to remember something true. malloc takes number of bytes.
> calloc takes number of elements and number of bytes per element but
> involves extra overhead which is not needed here.
calloc() = malloc() + memset() ??
> After free(current), current is indeterminate and doesn't point
> anywhere. Whether or not you set current to NULL after the free, any
> attempt to dereference current, as in the expression current->next,
> invokes undefined behavior.
understood very well.
> >> Since you have managed to create the situation, you might also want to
> >> add the following to the end of the if:
> >> || q->tail->next != NULL
> True. I apologize for my excess sarcasm.
ah.. cmon Barry. I liked your sarcasm, especially this one:
"Since you have managed to create the situation, you might also want
to add the following to the end of the if: || q->tail->next !=
NULL "
Becaus of that I realized my checks were stupid. Checks are good but
not the ones I am doing , they are programming errors. Still can't
figure out how to remove an element from queue :\
On Thursday, May 10, 2012 1:26:52 PM UTC+1, arnuld wrote:
> > On May 9, 10:59 pm, Barry Schwarz <schwa...@dqel.com> wrote:
> >> On 09 May 2012 13:18:08 GMT, arnuld <sunr...@invalid.address> wrote:
> >>Because it makes me remember that malloc() takes number of elements.
no. The parameter is the number of bytes (chars)
> >> It
> >>sounds strange but I do forget to add number of elements most of the
> >>times.
> > Better to remember something true. malloc takes number of bytes.
> > calloc takes number of elements and number of bytes per element but
> > involves extra overhead which is not needed here.
> calloc() = malloc() + memset() ??
depends what your "+" ooperator does! Note calloc() allocates an array of elements. But I'm sure most implementations of calloc() call malloc() (or both call some internal allocator)
> WANTED: Removing all elements matching a particular key from a Queue
> WHAT I GOT: Segfault
> WANTED: Segfaults in removeAllMatches(). I think routine/fucntion is too > complex to be understood. removeAllMatches(arg1, arg2) is supposed to > remove all elements from arg1 which match value of arg2.
<arnuld.miz...@gmail.com> wrote:
>> Better to remember something true. malloc takes number of bytes.
>> calloc takes number of elements and number of bytes per element but
>> involves extra overhead which is not needed here.
>calloc() = malloc() + memset() ??
As long as malloc doesn't fail,
calloc(a,b) = memset(malloc(a*b),0,a*b)
On Tue, 15 May 2012 17:42:46 -0400, lawrence.jo...@siemens.com wrote:
>Barry Schwarz <schwa...@dqel.com> wrote:
>> As long as malloc doesn't fail,
>And a*b doesn't overflow,
>> calloc(a,b) = memset(malloc(a*b),0,a*b)
Unsigned arithmetic cannot overflow.
Given the wording in 7.20.3.1, where the allocated space constitutes a
single array, I have no idea what happens when the arithmetic product
a*b exceeds the value of SIZE_MAX. Under such conditions I believe
calloc should fail and return NULL but the memset expression above is
under no such obligation.
> Given the wording in 7.20.3.1, where the allocated space constitutes a
> single array, I have no idea what happens when the arithmetic product
> a*b exceeds the value of SIZE_MAX. ...
calloc(a,b) must either return a pointer to enough memory to store 'a'
objects, each of size 'b' bytes, or a null pointer. If the mathematical
product of a*b is greater than SIZE_MAX, then (size_t)(a*b) bytes will
not be sufficient to meet that requirement - but the requirement still
holds. Therefore, calloc(a,b) must either return a null pointer, or
allocate sufficient memory by some mechanism other than malloc(a*b).
-- James Kuyper