Board index » cppbuilder » Data Breakpoints

Data Breakpoints


2007-05-25 06:42:38 PM
cppbuilder41
Dear,
anyone knows if there are bugs of BCB6 (Update 4) about managing Data
Breakpoints?
Best Regards,
Mauro Russo.
 
 

Re:Data Breakpoints

"Duane Hebert" < XXXX@XXXXX.COM >wrote:
Quote
>"Duane Hebert" wrote:
>>
>>Maybe he could just show us the function? Sounds like he's using
>>c_str() from an AnsiString after the AnsiString is gone. It's hard to
>>tell though with the "hints" about threads and such.
>
>It is not that. The String is an automatica variable and so its
>destruction is added
>by the compiler at the end of its scope.
>I could verify the problem by looking the run in disassembly mode.
>Note that my application is multi-thread and the acces violation happends
>only sometimes.
>When it does not happend, the c_str() value is correct.
>When it happends, I can note the c_str() value became 0x0E.
>

Yes but c_str() is a temporary. If the AnsiString gets destroyed
then I would expect just what you describe. If the AnsiString is in
another thread from where you're using the temporary c_str(), this
isn't going to work.
My AnsiString is declared inside the method and is set only at the
beginning.
The call of the desctructor fails and gets the Access Violation because of
the value 0x0E
instead of the correct pointer value.
Quote
>I need the Data Breakpoint working correctly to find out what corrupts
>that value,
>but I am having problems in using the Data Breakpoint. It seems to don't
>work.

I have no idea why your breakpoint isn't working.

My guess would be that the AnsiString is gone and you're c_str() is
trashed.
I do not use c_str(). I used it just to exaplin what I understood by looking
the
run in disassembly mode. I saw a bad c_str() just before the destructor is
called
and so I understood the motivation of the Access Violation.
I set the String only one time at the beginning of the method.
Quote
Try this, for example:

AnsiString a("hello");
char* ptr = a.c_str();
a = "";
ptr[2] = 'q';

//inspect ptr here...
I believeI will see in ptr the pointer to the old characted arrays. Of
course bad.
It is not my case.
Quote
>
>Thanks for your help.
You're going to need to show some code to give us a chance
to help you. The best would be to show the function that you're
having problems with for starters.
I can also report that I added, for debugging, such code after having set my
string:
const char *SavedCStr = MyString.c_str();
and then, in more points of my method, the code
if (SavedCStr != MyString.c_str())
CallDebug();
In different runs I could see that the CallDebug is called from different
points.
It pushed me to think that the corruption is because of some other thread
doing
something bad. Moreover, the access violation does not always happend in
that method.
It is in 80% of cases. I think I am lucky it almost always happends in that
method because,
if the Data Breakpoint will work, I can use it to check the writing on that
stack location and
find out the guilty code.
I tried the following strategy:
stopping with Code Breakpoint inside the method and read the stack location
where the c_str() is saved.
Adding a Data Breakpoint with that location. Of course, I need to be sure to
breaks the code only when
my method is running. So I added a global integer variabile, set to 1 when
the method starts and set to 0
when the method terminates. I can use its value for a condition of the Data
Breakpoints. I need to do it
because the most of times the method ends without any corruption of that
stack location.
My problem is that the Breakpoints never breaks. It does not break also if
the condition is "true" and
my method is running [and of course my methhod writes in that stack location
when the statement
"MyString = FunctionReturningStrin()" ends].
Mauro.
 

Re:Data Breakpoints

"mauro" < XXXX@XXXXX.COM >wrote in message
Quote

const char *SavedCStr = MyString.c_str();

and then, in more points of my method, the code

if (SavedCStr != MyString.c_str())
CallDebug();
I know that you're frustrated but you have to understand
that no one is going to be able to help you unless
you show them some code. For example, this
bit above probably isn't doing what you think it
is.
Try to simplify your code to the bare minimum that exhibits
the problem. If, at that point, you have not solved it, post
it here.
 

{smallsort}

Re:Data Breakpoints

"Duane Hebert" wrote
Quote
>const char *SavedCStr = MyString.c_str();
>
>and then, in more points of my method, the code
>
>if (SavedCStr != MyString.c_str())
>CallDebug();

I know that you're frustrated but you have to understand
that no one is going to be able to help you unless
you show them some code. For example, this
bit above probably isn't doing what you think it
is.

Try to simplify your code to the bare minimum that exhibits
the problem. If, at that point, you have not solved it, post
it here.
Dear, I am really sorry. I know for you it is difficult to help me until you
do not see the code.
But really, what I am trying to discuss is if to decide with you if
a) discuss about the code of that method
b) believe that an other thread corrupts the things.
So I tried to give you all elements to try to decide first which path to
follow, a) or b).
The used the code
if (SavedCStr != MyString.c_str())
CallDebug();
to check in what part of the method there was the corruption.
I pushed a copy of such little test in more points of the method and I added
a breakpoint in the CallDebug function.
The result was that the first point where the CallDebug() has been called
changes every time the run restart.
I know it does not surely mean that the guilty is an other thread, but I
believe
(and I hope you can give me your opinion about that) that this is the most
probable.
In fact I started this question pointing on the use of the Data Breakpoint.
I also really appreciated you tried to help me also about the code, and in
fact I tried to answer about all doubts you proposed me.
I know also that if you do not see the code you will have always
thousands of doubts about my code.
As told in an other message, the Access Violation to very low address (0x06
or 0x00)
sometimes happends also in other threads and in other code.
In fact, when I tried to reduce at minimal the code to get the same Access
Violation to the
same point, the result was that the Access Violation always happends
somewhere else.
At the moment I am also sure that the code I need to show you is too much.
That is the motivation I pointed on the discussion on Data Breakpoints. If
it does not
give any result, I will work more (it is not so easy now) to reduce the code
to show you
and I will do it.
Anywhere, really thanks for your help.
 

Re:Data Breakpoints

"mauro" < XXXX@XXXXX.COM >wrote in message
Quote
As told in an other message, the Access Violation to very low address
(0x06 or 0x00)
sometimes happends also in other threads and in other code.
In fact, when I tried to reduce at minimal the code to get the same Access
Violation to the
same point, the result was that the Access Violation always happends
somewhere else.
This seems to imply that the problem is somewhere else.
This sort of heisen bug is particularly difficult to find
in threaded apps. One clue could be that it's seems to at least
sometimes be an attempt to access null. But without a stack
trace from the de{*word*81} this will be tough to find.
Quote
At the moment I am also sure that the code I need to show you is too much.
That is the motivation I pointed on the discussion on Data Breakpoints. If
it does not
give any result, I will work more (it is not so easy now) to reduce the
code to show you
and I will do it.

Anywhere, really thanks for your help.
Let us know how you make out with std::string.
 

Re:Data Breakpoints

"Duane Hebert" < XXXX@XXXXX.COM >ha scritto nel messaggio
Quote

"mauro" < XXXX@XXXXX.COM >wrote in message
news:46577444$ XXXX@XXXXX.COM ...
>As told in an other message, the Access Violation to very low address
>(0x06 or 0x00)
>sometimes happends also in other threads and in other code.
>In fact, when I tried to reduce at minimal the code to get the same
>Access Violation to the
>same point, the result was that the Access Violation always happends
>somewhere else.

This seems to imply that the problem is somewhere else.
This sort of heisen bug is particularly difficult to find
in threaded apps. One clue could be that it's seems to at least
sometimes be an attempt to access null. But without a stack
trace from the de{*word*81} this will be tough to find.


>At the moment I am also sure that the code I need to show you is too
>much.
>That is the motivation I pointed on the discussion on Data Breakpoints.
>If it does not
>give any result, I will work more (it is not so easy now) to reduce the
>code to show you
>and I will do it.
>
>Anywhere, really thanks for your help.

Let us know how you make out with std::string.
I will do. First of that, I am trying to give to the main thread the role of
two suspected thread (one per time).
In fact I am afraid that, if with std::string, it works, I cannot be sure it
was really the motivation.
So, I hope that the Data Breakpoint (from the main thread) will show me that
some AnsiString method is guilty.
I will let you know the following of the history :)
Thanks for help,
Mauro.