My code is going out of bounds

[tunage]

I am really unsure how to keep within the boundries and still perform the function I need.
My code functions normal when I have both categories 'buy' and 'sell' in the queue which is my main goal and I should be clocked out on this function BUT,,,
If the queue is missing all 'sell' data, it segment faults.
I don't want to change any of the functionality, just get rid of the segment fault error.
It appears b < buydat.size() and buydat[b+1] are in conflict.
The purpose of the algorithm is capture the record sets in groups of 7 from data coming in from the www as strings. In that group/set, I pattern match for the string 'Buy' and if true, insert record into vector for processing. I also need the price (y = 3)

How do I capture buydat[2] and buydat[3] in groups of 7 without a segment fault?

void buymngr(){
        //vector defs
        vector<std::string> buydat;
        vector<std::string> markdat;
        vector<std::string> pricedat;
        vector<std::string> qworkcoin;

        buydat = getmyData();
        markdat = getmarketbuyData();
        cout << "Bork!" << endl;
		//This if statement was put here to try and prevent running code if missing data (seg fault patch)
		//It does not work and if category 'sell' is missing, it will fail to 'True' and run anyway then segment fault
        //if(!buydat.empty()){
        if(buydat[2] == std::string("Buy")){
                cout << "Bork2!" << endl;
                for(int b = 2; b < buydat.size(); b+=7){
                        int y = 3;  y+=7;
                        if ( buydat[b] == "Buy" ) {
                                pricedat.push_back(buydat[b+1]);
								//segment fault here
                                qworkcoin.push_back(buydat[y+1]);
                        }
				}
		}

gentoo-mini # cat getmyData.h

#include <vector>
using namespace std;

vector<string> getmyData()
{
        FILE *mydfp = popen("php getMyorders.php 155", "r");
        if (mydfp == NULL) perror ("Error opening file");
        char mydbuff[BUFSIZ];
        vector<string> vrecords;
        while(fgets(mydbuff, sizeof(mydbuff), mydfp) != NULL){
                size_t n = strlen(mydbuff);
                //clean '\0' from fgets
                if (n && mydbuff[n - 1] == '\n') mydbuff[n - 1] = '\0';
                if (mydbuff[0] != '\0') vrecords.push_back(mydbuff);
                //if (mydbuff[0] != '\0') vrecords.push_back("0.001");
                //vrecords.push_back("0.003");
                //vrecords.push_back("0.0032");
                //vrecords.push_back("0.0033");
                //vrecords.push_back("0.0034");
        }
        cout << "I got my own data" << endl;
        return vrecords;
}

When one buy and one sell are sitting in the queue. Code functions as expected:

gentoo-mini # ./masterMain

I got my own data
I just got market buy data
Bork!
Bork2!
You 'do' have buy string match data!
my max price is 0.00492975 at position 0
market max price is 0.00560504 at position 0
Highest is market!0.005605 0.00100000
php buycoin.php 155 0.005605 0.00100000 Command
0.005605 0.00100000 sendbuy
0.005605 0.00100000 mkbuybuff
0.00560505 *biggestMark
0.00100000
You bought coins, you are now top buyer
I got my own data
I just got market sell data
my min price is 0.00760479 at position 0
market min price is 0.00564973 at position 0
Lowest is market!php sellcoin.php 155 0.00564972
0.00564972
226250684

Data from the www following is as expected:

gentoo-mini # php getMyorders.php 155

224122032
2014-12-21 18:17:43
Buy
0.00492975
0.00010000
0.00010000
0.00000049
226250651
2014-12-26 10:56:48
Buy
0.00560500
0.00100000
0.00100000
0.00000561
226250684
2014-12-26 10:56:55
Sell
0.00564972
0.00100000
0.00100000
0.00000565
226250585
2014-12-26 10:56:31
Sell
0.00760479
0.00100000
0.00100000
0.00000760

BUT,,,
If I clear sell data and have only buy data in the queue, I get a segment fault:

gentoo-mini # ./masterMain

I got my own data
I just got market buy data
Bork!
Bork2!
Segmentation fault

Data sitting in queue is as follows:

gentoo-mini # php getMyorders.php 155

224122032
2014-12-21 18:17:43
Buy
0.00492975
0.00010000
0.00010000
0.00000049

gdb

gentoo-mini # gdb masterMain

GNU gdb (Gentoo 7.7.1 p1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from masterMain...done.
(gdb) run
Starting program: masterMain
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
I got my own data
I just got market buy data
Bork!
Bork2!

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b9355b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6
(gdb) bt
#0  0x00007ffff7b9355b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6
#1  0x0000000000404ffc in __gnu_cxx::new_allocator<std::string>::construct<std::string<std::string const&> > (this=0x7fffffffbfc0, __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/ext/new_allocator.h:120
#2  0x0000000000404b19 in std::allocator_traits<std::allocator<std::string> >::_S_construct<std::string<std::string const&> >(std::allocator<std::string>&, std::allocator_traits<std::allocator<std::string> >::__construct_helper*, (std::string<std::string const&>&&)...) (__a=..., __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/alloc_traits.h:254
#3  0x0000000000404123 in std::allocator_traits<std::allocator<std::string> >::construct<std::string<std::string const&> >(std::allocator<std::string>&, std::string<std::string const&>*, (std::string<std::string const&>&&)...) (__a=...,
    __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/alloc_traits.h:393
#4  0x00000000004041ad in std::vector<std::string, std::allocator<std::string> >::_M_emplace_back_aux<std::string const&> (this=0x7fffffffbfc0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/vector.tcc:408
#5  0x0000000000403a69 in std::vector<std::string, std::allocator<std::string> >::---Type <return> to continue, or q <return> to quit---   q
Quit
(gdb)
#0  0x00007ffff7b9355b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6
#1  0x0000000000404ffc in __gnu_cxx::new_allocator<std::string>::construct<std::string<std::string const&> > (this=0x7fffffffbfc0, __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/ext/new_allocator.h:120
#2  0x0000000000404b19 in std::allocator_traits<std::allocator<std::string> >::_S_construct<std::string<std::string const&> >(std::allocator<std::string>&, std::allocator_traits<std::allocator<std::string> >::__construct_helper*, (std::string<std::string const&>&&)...) (__a=..., __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/alloc_traits.h:254
#3  0x0000000000404123 in std::allocator_traits<std::allocator<std::string> >::construct<std::string<std::string const&> >(std::allocator<std::string>&, std::string<std::string const&>*, (std::string<std::string const&>&&)...) (__a=...,
    __p=0x60a1b0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/alloc_traits.h:393
#4  0x00000000004041ad in std::vector<std::string, std::allocator<std::string> >::_M_emplace_back_aux<std::string const&> (this=0x7fffffffbfc0)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/vector.tcc:408
#5  0x0000000000403a69 in std::vector<std::string, std::allocator<std::string> >::---Type <return> to continue, or q <return> to quit---
push_back (this=0x7fffffffbfc0,
    __x=<error reading variable: Cannot access memory at address 0xfffffffffffffff2>)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/bits/stl_vector.h:911
#6  0x0000000000401e62 in buymngr () at buymngr.h:38    (actually pointing to line 18 -> qworkcoin.push_back(buydat[y+1]);))
#7  0x000000000040329f in main () at masterMain.cpp:25

[tunage]

this was posted to the wrong section :/

[razzle]

How do I capture buydat[2] and buydat[3] in groups of 7 without a segment fault?

By applying stepwise refinement.

Develop you code in small increments from start to finish. Make sure it works as intended in each step.

The worst thing you can do is be sitting with a pile of crappy code having no clue, like now.

[tunage]

By applying stepwise refinement.

Develop you code in small increments from start to finish. Make sure it works as intended in each step.

The worst thing you can do is be sitting with a pile of crappy code having no clue, like now.

Thank you very little!
I won't remember that...

[razzle]

Thank you very little!
I won't remember that...

That's too bad because then you're a programmer without future.

It's so simple it almost hurts. You start with a small working program. Then you develop it in small working steps. And you end up with a big working program.

It's called the principle of Stepwise Refinement and if you apply it consistently you'll soon be guru programmer.

[2kaud]

It appears b < buydat.size() and buydat[b+1] are in conflict.

Correct. buydat[] has a range of 0 to size() - 1. So if size is 10, buydat[] has a range of 0 to 9. So in this case if b is 9, b is less than .size() (so the test is true) but b + 1 is out of bounds (gives segment fault) as buydat[10] is not valid.

The 'easy' solution could be

for(int b = 2; b < buydat.size() - 1; b+=7){

This will terminate the loop when b is less than .size() - 1, so now b + 1 is a valid index into buydat[].

PS. When trying to find run-time issues with a program use the debugger to trace through the program to see values of variables etc when the code doesn't execute as expected.

[tunage]

By applying stepwise refinement.

Develop you code in small increments from start to finish. Make sure it works as intended in each step.

The worst thing you can do is be sitting with a pile of crappy code having no clue, like now.

I had asked a very specific question on the mechanics and you provided a very abstract and theoretical response, a very condescending one at that.
Personally I find the rubber duckie method to be far more robust and professional http://en.wikipedia.org/wiki/Rubber_duck_debugging but the only issue is, what was coming from his quacker was trash. I was looking at it 'mechanically' wrong.
Now, the gentleman below you did a superior job of providing a 'functional' response that answers many of the questions I had and probably will assist many readers..

[GCDEF]

I had asked a very specific question on the mechanics and you provided a very abstract and theoretical response, a very condescending one at that.
Personally I find the rubber duckie method to be far more robust and professional http://en.wikipedia.org/wiki/Rubber_duck_debugging but the only issue is, what was coming from his quacker was trash. I was looking at it 'mechanically' wrong.
Now, the gentleman below you did a superior job of providing a 'functional' response that answers many of the questions I had and probably will assist many readers..

Given that you had to ask how to debug an array out of bounds question, your preferred debugging method isn't really of much interest. You've got some seriously good and experienced programmers helping you for free. If you plan on using the forum regularly, you'll find being snappish isn't going to get you very far.