C++ Runtime Error (v5) (shared_ptr.hpp)

[Bot-Factory 602]

Has someone seen this error before?

 

 

Just tested one of my multithreading bots in v5. 

Running 25 threads. Scraping 50000 items into a list.

 

Works perfectly fine in v4. 

 

In v5 (compiled bot) it crashes after round about 20-25k items.

 

 

I know about the support system. Just wanted to know if someone has seen this before?

 

Dan

[Pete 121]

Yes but some time ago now so I can't remember what triggered it of the top of my head now

But you’ll not alone

[Bot-Factory 602]

Yes but some time ago now so I can't remember what triggered it of the top of my head now

But you’ll not alone

With V5 or also with V4?

 

Dan

[Pete 121]

Only with version 5,

[ptlrc 2]

yeah, i got this error too

[the_way 52]

what the heck is boost boost boost?

[a2mateit 395]

http://www.boost.org/

 

I'm guessing that v5 is using some of their libraries...

[ptlrc 2]

uninstall the ubot5, ubot 4, and delete the appdata/ubotstudio file, and reinstall ubot 5, then error gone

 

but the browser still crashes and pages turn blank

[Bot-Factory 602]

I'm still getting that error. And it's always in Line 653.

 

So please UBot team. Take a look at the stuff you do in line 653 :-)

 

 

Thanks

Dan

[meter 145]

Actually that's line 653 of boost's shared_ptr.hpp. The Ubot error is somewhere up the call stack I imagine, and is probably Ubot trying to use a pointer in one thread that has been deleted in another thread. These kinds of bugs are notoriously hard to fix.

 

Sorry to be pedantic

 

-meter

[Bot-Factory 602]

Thanks a lot Meter,

 

not pedantic at all. I think it all helps to solve the problem.

 

I also found some interesting information's:

http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/shared_ptr.htm#BestPractices

 

 

 

Best Practices

A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new. Every occurence of the new keyword in the code should have the form:

shared_ptr<T> p(new Y);

It is, of course, acceptable to use another smart pointer in place of shared_ptr above; having T and Y be the same type, or passing arguments to Y's constructor is also OK.

If you observe this guideline, it naturally follows that you will have no explicit deletes; try/catch constructs will be rare.

Avoid using unnamed shared_ptr temporaries to save typing; to see why this is dangerous, consider this example:

void f(shared_ptr<int>, int);
int g();

void ok()
{
shared_ptr<int> p(new int(2));
f(p, g());
}

void bad()
{
f(shared_ptr<int>(new int(2)), g());
}

The function ok follows the guideline to the letter, whereas bad constructs the temporary shared_ptr in place, admitting the possibility of a memory leak. Since function arguments are evaluated in unspecified order, it is possible for new int(2) to be evaluated first, g() second, and we may never get to theshared_ptr constructor if g throws an exception. See Herb Sutter's treatment (also here) of the issue for more information.

The exception safety problem described above may also be eliminated by using the make_shared or allocate_shared factory functions defined in boost/make_shared.hpp. These factory functions also provide an efficiency benefit by consolidating allocations.

[Eddie 14]

i got the same error, is anybody know how to resolve it?

[Bot-Factory 602]

With what version of ubot?

[Eddie 14]

With what version of ubot?

ubot 4.

[Pete 121]

What versions of microsoft visual C++ are you guys running
As I only had the x64 versions installed, and just thought ubot is still x86