[archive] Tracking Down MAV errors in thin Client

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

The specific problem we are having with Mav's is has only been indetified in version 7.2, it has been mentioned that 8.0 may be better we do not know.

The one case where we are getting MAV's in Thin client that it works in fat client I would probably call a case of the Fat client being more forgiving than the Thin Client. The sequence of events is this.
1. Destroy All is issued,
2. A destroy screen passing the TAB handle is issued,
3. a destroy screen using the window handle is issued.
All of which destroy some or all of the same "STANDARD" window which is displayed by our application.

This is done to "clean up" at the end of a program, and when the first display of the next program is attempted a mav results when running under thin client but not under standard acucobol.

If you take out the destroy all, or change the destroy screens to close screens (you have to change the standard window to a floating window) the problem goes away.

We identified this issue almost 4 weeks ago an in that time we have reviewed the code, and looked at coding practices and realize that several of these practices are questionable at best, so we are trying to work around the problem by cleaning up our code.

Micro Focus has some sample code that creates the problem, and 3 weeks ago acknoledged that they could replicate it, We have not got any other information about the issue. (they are working on it, I hear from my rep a couple of times a week to get an update).

When we talked to one of their SE's about how to resolve the problem he told me that he never used Destroy All, because he used AcuBench and it did not create any of them in it's code.

I certainly would not call ourselves the experts in this issue, this is just our experience.

As for running on thin Client rather than fat, I would agree it is not a lot of work, but it is some work, things like "save a file print to disk" one of our points in using thin client was so our application users would not have to have "user access" on the server, and so the server could be linux. So we wanted the print files to be saved to the PC, not the server, we had to write some extra code to do that, there is no "save to local disk" command you have to call a "copy file" function. little things like that, not a lot of them, in our case maybe a half a dozen of them.

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

The specific problem we are having with Mav's is has only been indetified in version 7.2, it has been mentioned that 8.0 may be better we do not know.

The one case where we are getting MAV's in Thin client that it works in fat client I would probably call a case of the Fat client being more forgiving than the Thin Client. The sequence of events is this.
1. Destroy All is issued,
2. A destroy screen passing the TAB handle is issued,
3. a destroy screen using the window handle is issued.
All of which destroy some or all of the same "STANDARD" window which is displayed by our application.

This is done to "clean up" at the end of a program, and when the first display of the next program is attempted a mav results when running under thin client but not under standard acucobol.

If you take out the destroy all, or change the destroy screens to close screens (you have to change the standard window to a floating window) the problem goes away.

We identified this issue almost 4 weeks ago an in that time we have reviewed the code, and looked at coding practices and realize that several of these practices are questionable at best, so we are trying to work around the problem by cleaning up our code.

Micro Focus has some sample code that creates the problem, and 3 weeks ago acknoledged that they could replicate it, We have not got any other information about the issue. (they are working on it, I hear from my rep a couple of times a week to get an update).

When we talked to one of their SE's about how to resolve the problem he told me that he never used Destroy All, because he used AcuBench and it did not create any of them in it's code.

I certainly would not call ourselves the experts in this issue, this is just our experience.

As for running on thin Client rather than fat, I would agree it is not a lot of work, but it is some work, things like "save a file print to disk" one of our points in using thin client was so our application users would not have to have "user access" on the server, and so the server could be linux. So we wanted the print files to be saved to the PC, not the server, we had to write some extra code to do that, there is no "save to local disk" command you have to call a "copy file" function. little things like that, not a lot of them, in our case maybe a half a dozen of them.

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

The specific problem we are having with Mav's is has only been indetified in version 7.2, it has been mentioned that 8.0 may be better we do not know.

The one case where we are getting MAV's in Thin client that it works in fat client I would probably call a case of the Fat client being more forgiving than the Thin Client. The sequence of events is this.
1. Destroy All is issued,
2. A destroy screen passing the TAB handle is issued,
3. a destroy screen using the window handle is issued.
All of which destroy some or all of the same "STANDARD" window which is displayed by our application.

This is done to "clean up" at the end of a program, and when the first display of the next program is attempted a mav results when running under thin client but not under standard acucobol.

If you take out the destroy all, or change the destroy screens to close screens (you have to change the standard window to a floating window) the problem goes away.

We identified this issue almost 4 weeks ago an in that time we have reviewed the code, and looked at coding practices and realize that several of these practices are questionable at best, so we are trying to work around the problem by cleaning up our code.

Micro Focus has some sample code that creates the problem, and 3 weeks ago acknoledged that they could replicate it, We have not got any other information about the issue. (they are working on it, I hear from my rep a couple of times a week to get an update).

When we talked to one of their SE's about how to resolve the problem he told me that he never used Destroy All, because he used AcuBench and it did not create any of them in it's code.

I certainly would not call ourselves the experts in this issue, this is just our experience.

As for running on thin Client rather than fat, I would agree it is not a lot of work, but it is some work, things like "save a file print to disk" one of our points in using thin client was so our application users would not have to have "user access" on the server, and so the server could be linux. So we wanted the print files to be saved to the PC, not the server, we had to write some extra code to do that, there is no "save to local disk" command you have to call a "copy file" function. little things like that, not a lot of them, in our case maybe a half a dozen of them.

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Gisle/Rob

Thanks for that - it make me feel much better regarding possible moves to Thin Client.
Keith

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Gisle/Rob

Thanks for that - it make me feel much better regarding possible moves to Thin Client.
Keith

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Keith,

Further to the above.
We have 1 particulary large installion with our sales/distribution product.
They were on 6.1.0, this runtime (unix version by the way) ended up getting very heavily patched by San Diego and on advice from UK support & our account manager at the time we decided that we should upgrade to 7.2.

Safe to say that pretty much all hell broke loose with that customer, and we changed our code ever so slightly under advice from Acucorp.
San Diego gave us another 4 patches in total for the runtime over the space of maybe 7 or 8 weeks.
Things settled pretty quickly to a level that the customer was happyish with.
The curent setup is that they still experience MAV's, we've found ourselves possible causes of these MAV's and Acucorp investigated with found that V8.0 cured a lot of them.
Mainly memory leaks, I believe Gisle here kindly responded to the thread I started saying that they were because of mirrored handles.

We've learned our lesson and have been extensively testing V8.0 internally.
All I can say is so far so good, the memory leaks we were experiencing (3 different examples) are gone.
There was one memory leak in particular which was loosing over 1,000 byes every time.

We're planning on upgrading that customer and all others early in the new year.

We also use acubench, we do not destroy all or every control.

Acubench itself destroy's the screen-handle after the accept terminates
We then on top of this destroy bitmaps & menus & any fonts we load manually.
My previous thread showed that we displayed the memory usage in the debugger to prove that all memory was freed up just before the EXIT PROGRAM.

Shaun

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Keith,

Further to the above.
We have 1 particulary large installion with our sales/distribution product.
They were on 6.1.0, this runtime (unix version by the way) ended up getting very heavily patched by San Diego and on advice from UK support & our account manager at the time we decided that we should upgrade to 7.2.

Safe to say that pretty much all hell broke loose with that customer, and we changed our code ever so slightly under advice from Acucorp.
San Diego gave us another 4 patches in total for the runtime over the space of maybe 7 or 8 weeks.
Things settled pretty quickly to a level that the customer was happyish with.
The curent setup is that they still experience MAV's, we've found ourselves possible causes of these MAV's and Acucorp investigated with found that V8.0 cured a lot of them.
Mainly memory leaks, I believe Gisle here kindly responded to the thread I started saying that they were because of mirrored handles.

We've learned our lesson and have been extensively testing V8.0 internally.
All I can say is so far so good, the memory leaks we were experiencing (3 different examples) are gone.
There was one memory leak in particular which was loosing over 1,000 byes every time.

We're planning on upgrading that customer and all others early in the new year.

We also use acubench, we do not destroy all or every control.

Acubench itself destroy's the screen-handle after the accept terminates
We then on top of this destroy bitmaps & menus & any fonts we load manually.
My previous thread showed that we displayed the memory usage in the debugger to prove that all memory was freed up just before the EXIT PROGRAM.

Shaun

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Markr,

I think you are correct in that "fat client" is more forgiving than thin client. I think that's one of the reasons we found issues is because of questionable coding practices on our part. At least that was part of it. If it's been working for 10 or 20 years....

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Markr,

I think you are correct in that "fat client" is more forgiving than thin client. I think that's one of the reasons we found issues is because of questionable coding practices on our part. At least that was part of it. If it's been working for 10 or 20 years....

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

Markr,

I think you are correct in that "fat client" is more forgiving than thin client. I think that's one of the reasons we found issues is because of questionable coding practices on our part. At least that was part of it. If it's been working for 10 or 20 years....

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

1. Destroy All is issued,
2. A destroy screen passing the TAB handle is issued,
3. a destroy screen using the window handle is issued.
All of which destroy some or all of the same "STANDARD" window which is displayed by our application.

If you have all you have displayed is in one single SCREEN SECTION item, DESTROY on the single screen section item is all it should take. If this SCREEN SECTION item is the one and only on that window, a DESTROY SCREEN screenhandle is all it should take.
Exception: Menues, fonts, bitmaps are considered global properties, and will need to be destroyed explicitely. If you have such, you should delete these *after* deleting the screen and window.

This is done to "clean up" at the end of a program, and when the first display of the next program is attempted a mav results when running under thin client but not under standard acucobol.

This sounds very much like a bug that is fixed, in certain circumstances the application would attempt to access a window/control that no longer existed.

never used Destroy All, because he used AcuBench
and it did not create any of them in it's code.

DESTROY ALL is a valid COBOL instruction, if it does not work it should be reported.

To summarize, it sounds to me you should try 8.0. I am pretty sure you should see your issues gone.

[Migrated content. Thread originally posted on 14 November 2007]

We are tracking a real painful problem, at a major client we are having between 60-90 MAV's (Memory Access Violations) a day on a system with 150 users. it is acu thin client 7.2 running on a linux server, with windows workstations.

We have created a test program that can replicate one situation that Acucobol has been looking at for a couple of weeks, but we know we have at least 2 more "types" of MAV's. We do arrary boundary checking, and all of the other things the manuals talk about. Most importantly we do not have this problem when running with "Standard Acucobol GT", however the size of the client precludes us from converting to this as a solution.

Does anyone know of some tools, or techniques to track down MAV's in thin client environment?

We thought that we could use the -m memory logging to track memory usage to see if we could find inconsistancies, but that did not work because the "realloc" command can change the address of the block of memory but the log entry does not show the new address.

Acucobol suggested using a product called "Valgrind" but our systems guys looked at it and seemed pretty sure you would need a debuggable version of the runtime, something I wouldn't expect a reasonable company to do.

So we are still looking for a needle in a big stack of needles -- anyone have any experience, thoughts, chants to ward of evils spirits :confused: , at this point we are willing to try most anything?

1. Destroy All is issued,
2. A destroy screen passing the TAB handle is issued,
3. a destroy screen using the window handle is issued.
All of which destroy some or all of the same "STANDARD" window which is displayed by our application.

If you have all you have displayed is in one single SCREEN SECTION item, DESTROY on the single screen section item is all it should take. If this SCREEN SECTION item is the one and only on that window, a DESTROY SCREEN screenhandle is all it should take.
Exception: Menues, fonts, bitmaps are considered global properties, and will need to be destroyed explicitely. If you have such, you should delete these *after* deleting the screen and window.

This is done to "clean up" at the end of a program, and when the first display of the next program is attempted a mav results when running under thin client but not under standard acucobol.

This sounds very much like a bug that is fixed, in certain circumstances the application would attempt to access a window/control that no longer existed.

never used Destroy All, because he used AcuBench
and it did not create any of them in it's code.

DESTROY ALL is a valid COBOL instruction, if it does not work it should be reported.

To summarize, it sounds to me you should try 8.0. I am pretty sure you should see your issues gone.