Jump to content
  • Advertisement
Sign in to follow this  
Dospro

Vector mock to catch bad accesses

This topic is 953 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone.

 

I'm maintaning some legacy code.

It used some crazy big plain arrays. So of course (with unit testing backing me off) i decided to use some std::vectors and std::arrays where they applied. Instead of big arrays, some small but well controlled arrays.

 

Everything was working fine but when i decided to actually delete one of the big plain array, some random crashes started to occur with very random error messages from the compiler. By experience, this smells like accesing vector/array bad locations. The code is far from clean now, but i need to find this outlimit acceses, so the tests keep succeding.

 

So, is there an alternative version of array/vector which actually throws and exception(or gives some message) when the index is outlimits?

Would it be a better idea to actually inherit from vector/array and override the index operator?

 

What do you say?

 

PD: The debugger won't help either in this case. The crashes are very random.

Share this post


Link to post
Share on other sites
Advertisement

I love std::vectors. Quick question, is any of the data your handling in your vectors pointers?

Edited by ExErvus

Share this post


Link to post
Share on other sites




Quote


I hate std::vectors.
I love std::vector. There are legitimate reasons not to use it in specific circumstances but anyone 'hating' it probably does not understand it well enough and would run into the same or worse problems with something hand-rolled.

 

"I hate std::vectors" was not a defining statement that they are terrible. I just don't like to use them. I am not discrediting their existence or ability to perform the job, I myself just have a personal dislike of them. Assuming someone's level of understanding is somewhat of an underhanded insult btw.

Share this post


Link to post
Share on other sites


So, is there an alternative version of array/vector which actually throws and exception(or gives some message) when the index is outlimits?

 

The MSVC debug libraries assert when you access std::vector or std::array out of bounds.

Share this post


Link to post
Share on other sites

Are this assertions compile-time or runtime?

The array acceses are not trivial.

 


Is your compiler actually crashing and giving you error messages? Or are you trying to say that your compiled program is crashing when you run it?

 

Yeah, sorry. When i run the program it crashes, not the compiler. By the way, i have isolated this kind of crash:

[xcb] Extra reply data still left in queue
[xcb] This is most likely caused by a broken X extension library
[xcb] Aborting, sorry about that.
program: /var/tmp/portage/x11-libs/libX11-1.6.3/work/libX11-1.6.3/src/xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed.
Abortado

It bugs me, because before the array refactorization, ir worked fine. So i guess it has to be something there.

 


Edit: For example for gcc's typical standard library you can add define _GLIBCXX_DEBUG and get nice error messages like this:

With this flag define nothing changes.

 


Of course the debugger helps even in those cases.

 

I'm using gcc4.9/gdb7.9 and gdb stops at an external library routine. It's like if some memory got corrupted, that's all the information i have gotten from gdb.

Share this post


Link to post
Share on other sites
Please refrain from offering unsolicited opinions on the use of standard library containers.

Further, please refrain from insulting and otherwise disparaging anyone who does post such opinions.

Share this post


Link to post
Share on other sites

Ok.

Using this flags in the compiler: -fsanitize=address -fstack-protector-all

together with the flag _GLIBCXX_DEBUG solved it. I was right, there were some out of bounds acceses.

No it works like a charm.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!