0

I think I found a simliar thread here, but I could not understand much about it unfortunately as this is related to c++. My prob also seems to occure while I am trying to increment something. Incrementing `static int` causes SIGSEGV SEGV_ACCERR

After looking at the above link,(as I have a feeling they are similar) the segmentation fault doesn't seem to occur always, the occurrence is pretty rare. The dump seems to happen in this function and when find is called.

Community
  • 1
  • 1
Rahul
  • 51
  • 1
  • 8
  • Static int wasn't the real problem in the question you linked to and I suspect it isn't for you either. The problem probably is somewhere in your find function. You might wish to use a memory debugger like valgrind. – Eelke Jul 07 '11 at 06:09
  • @Eelke - there is no valgrind on IA-64. wdb is used for this purposes. –  Jul 07 '11 at 06:13
  • @skwllsp, thanks for catching that, my fingers typed the wrong name... – Eelke Jul 07 '11 at 06:31
  • @Rahul, can you run your program under `gdb`? Or analyze a core file with the `bt` command under `gdb`? –  Jul 07 '11 at 07:05
  • Can you try to compile program on x86 or x86_64 and run it under valgrind? – osgx Jul 07 '11 at 08:08
  • I did it on x86, i could not hit the segv then ! :( the only hack i can give it make key = 0, which would go a further level and dump in hash, but my doubt is how can key become zero! i have already tried this situation earlier! – Rahul Jul 07 '11 at 08:47

1 Answers1

0

Seems like you try to give HashTbl::find key 0. It tries to dereference it and fails. Add printing key to std::out and check what keys you are using.

  • well, i d like to contradict a little bit.. as i said the core file seems to not be priting the correct values. so i dont think the key value is 0. Aside, can you tell me, how the key value can get zero? Because I dont see a possibility of key becoming zero, key == objectStatName. so can you think of a scenario when key can become zero? I think if you can make a theory out of that, it would be really helpful. if key was zero, then the bt would have gone one more step further and dumped at the hash call which it did not.. – Rahul Jul 07 '11 at 08:36
  • Well, you are right about key. By the way did you abalyze the core file or run the program under gdb? –  Jul 07 '11 at 09:11
  • is there a procedure i can find to run wdb? how can wdb help here. that is mostly for issues like memory leaks right? i am not sure if thats the case here. – Rahul Jul 07 '11 at 10:16
  • Sorry, did not understand you. Did you run your program under gdb? –  Jul 07 '11 at 10:37
  • mm_api_signal_recovery(), mm_set_signal_alarm() - is it your signal handlers? –  Jul 07 '11 at 10:46
  • For the experiment. Remove them in your code, do not set any signal handlers, compile the program again and see the core that you will get. Probably we will see the backtrace that is different and not corrupted –  Jul 07 '11 at 11:00
  • ok, i tried this again and gdb says this, pls see above thread where code is for find, i think the problem is in find – Rahul Jul 07 '11 at 13:42
  • Sorry, but I don't see any backtrace –  Jul 07 '11 at 13:52
  • i have pasted the find method (code) not the bt... can u see if anythings wrong around the line i have mentioned in find... – Rahul Jul 07 '11 at 14:00
  • Why not add output to std::cout for `key`? –  Jul 07 '11 at 14:08
  • ok.. i ll give that a shot. can yu think of a situation when key can become 0? just a question :) is that possible? – Rahul Jul 07 '11 at 14:15
  • I don't know. You even have not posted a backtrace. You can add `assert(key)` instead. –  Jul 07 '11 at 14:17
  • Hi guys, Can anyone point me to a link where I can find a design diagram for a hash table and its interacting with a freeList? The hashing technique I am talking about is not the linked list implementation, somethin like linear probing. – Rahul Jul 11 '11 at 05:31
  • You'd better ask this question as a separate question on this site. –  Jul 11 '11 at 12:51