Skip to main content

[archive] Tracking Down MAV errors in thin Client

  • November 15, 2007
  • 37 replies
  • 0 views
D

[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?

    37 replies

    D

    [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?
    Mark, tracking mav maybe not so useless if You can't refer to your cobol program, so You've to inquire in a different way:
    1) activate runtime log at maximum level (TF 9, and TP commands in debugger, see manuals for more infos on preparing cblconfi and "e" runtime option) to see at least programs incriminated, so to limit investigation points.
    2) try compile most programs in debug mode (-Zd option): in this case runtime uses a different way of using memory and, we experienced, is more strong and resistent to memory fault.
    3) look at your in-code API's calls there's a big difference in calling API's with Wrun32 and with Thin client: all pointers must refer to client side.
    4) be careful at destroying handles of Graphical objects you create: due to the fact you got mav's in Thin env it seems to be related with graphical controls.
    5) sometimes With MS VisualStudio and Visual C env installed I got a debug point on Mav's but, it's assembly, not easy to understand and as your system persons said, not so useful without a debuggable runtime.
    Hope this helps.
    Bye Giovanni
    D

    [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?
    Mark, tracking mav maybe not so useless if You can't refer to your cobol program, so You've to inquire in a different way:
    1) activate runtime log at maximum level (TF 9, and TP commands in debugger, see manuals for more infos on preparing cblconfi and "e" runtime option) to see at least programs incriminated, so to limit investigation points.
    2) try compile most programs in debug mode (-Zd option): in this case runtime uses a different way of using memory and, we experienced, is more strong and resistent to memory fault.
    3) look at your in-code API's calls there's a big difference in calling API's with Wrun32 and with Thin client: all pointers must refer to client side.
    4) be careful at destroying handles of Graphical objects you create: due to the fact you got mav's in Thin env it seems to be related with graphical controls.
    5) sometimes With MS VisualStudio and Visual C env installed I got a debug point on Mav's but, it's assembly, not easy to understand and as your system persons said, not so useful without a debuggable runtime.
    Hope this helps.
    Bye Giovanni
    D

    [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?
    Giovanni,

    Thanks that gives us someplace to start.

    You are right about destroying handles of graphical objects. We traced a bit of code which did in the following order 1. Destroy Screen, 2. Destroy Tab, 3. Destroy ALL. (I realize that this doesn't make any sense to do this) it works find in Wrun32, but in thin client the next time we try to display something on the screen (even if we create a new window) we get a MAV. We are trying to take all the destroy all's all of our software but we aren't sure what they do or how it will effect our software.

    Additionally we found another MAV where in the trace file the handle to a file became null just before a MAV, we don't know if that could be related or not. (see attachment for part of the log file ) Could this be related to the same problem of destroying a graphical control, and it "destroyed" the wrong thing.

    When you say be careful how to use destroy do you have a couple of suggestions about how to appropriately use the verb.

    Thanks

    Mark
    D

    [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?
    Giovanni,

    Thanks that gives us someplace to start.

    You are right about destroying handles of graphical objects. We traced a bit of code which did in the following order 1. Destroy Screen, 2. Destroy Tab, 3. Destroy ALL. (I realize that this doesn't make any sense to do this) it works find in Wrun32, but in thin client the next time we try to display something on the screen (even if we create a new window) we get a MAV. We are trying to take all the destroy all's all of our software but we aren't sure what they do or how it will effect our software.

    Additionally we found another MAV where in the trace file the handle to a file became null just before a MAV, we don't know if that could be related or not. (see attachment for part of the log file ) Could this be related to the same problem of destroying a graphical control, and it "destroyed" the wrong thing.

    When you say be careful how to use destroy do you have a couple of suggestions about how to appropriately use the verb.

    Thanks

    Mark
    D

    [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?
    Hi Mark,
    1) basic suggestion to destroy is:
    destroy objects in a LIFO sequence: first destroy the last you create, moreover destroy objects only when you don't need them no more.
    2) screen must not destroyed but must be closed via close window verb
    3) take extreme care of handling all events (api messages) on control and of executing the code to keep empty the message queue of a control: if you try to destroy a control that still has got some messages in previous thin versions (I think till 7.0.1) caused mavs: trick set them not visible before destroying so to prevent user input on them.
    4) for the file: handles to files are due of runtime, mav maybe a side effect of another other mav or check code if you use external files, in this case take care of canceling called programs in case of no more use.
    Hope this helps and glad to be useful, bye Giovanni
    D

    [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?
    Hi Mark,
    1) basic suggestion to destroy is:
    destroy objects in a LIFO sequence: first destroy the last you create, moreover destroy objects only when you don't need them no more.
    2) screen must not destroyed but must be closed via close window verb
    3) take extreme care of handling all events (api messages) on control and of executing the code to keep empty the message queue of a control: if you try to destroy a control that still has got some messages in previous thin versions (I think till 7.0.1) caused mavs: trick set them not visible before destroying so to prevent user input on them.
    4) for the file: handles to files are due of runtime, mav maybe a side effect of another other mav or check code if you use external files, in this case take care of canceling called programs in case of no more use.
    Hope this helps and glad to be useful, bye Giovanni
    D

    [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?
    Hi Mark,
    1) basic suggestion to destroy is:
    destroy objects in a LIFO sequence: first destroy the last you create, moreover destroy objects only when you don't need them no more.
    2) screen must not destroyed but must be closed via close window verb
    3) take extreme care of handling all events (api messages) on control and of executing the code to keep empty the message queue of a control: if you try to destroy a control that still has got some messages in previous thin versions (I think till 7.0.1) caused mavs: trick set them not visible before destroying so to prevent user input on them.
    4) for the file: handles to files are due of runtime, mav maybe a side effect of another other mav or check code if you use external files, in this case take care of canceling called programs in case of no more use.
    Hope this helps and glad to be useful, bye Giovanni
    D

    [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?
    Mark,

    You will probably find that Giovanni's suggestions will help the most. We experienced the same thing. Also, keep in mind that there are some inherent timing differences between a standard windows runtime and thin client. This can cause problems within event procedures, etc.

    Rob
    D

    [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?
    Mark,

    You will probably find that Giovanni's suggestions will help the most. We experienced the same thing. Also, keep in mind that there are some inherent timing differences between a standard windows runtime and thin client. This can cause problems within event procedures, etc.

    Rob
    D

    [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?
    Couple of questions Mark.

    These are all based on our own experience, and fixed many faults for us - mainly MAV's

    Do you use Acubench?

    Do you use threads?

    Do you Events or Exceptions on push buttons?

    Do you use grids for inputting info?

    Can you replicate these issues in house, or is it only on a particular site?

    If you can replicate inhouse, I'd suggest that you get your hands on a copy of V8.0 as there are lots of fixes regarding MAV's and particularly in our own case memory leaks.
    Its something to do with mirrored handles in the runtime.

    Shaun
    D

    [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?
    Couple of questions Mark.

    These are all based on our own experience, and fixed many faults for us - mainly MAV's

    Do you use Acubench?

    Do you use threads?

    Do you Events or Exceptions on push buttons?

    Do you use grids for inputting info?

    Can you replicate these issues in house, or is it only on a particular site?

    If you can replicate inhouse, I'd suggest that you get your hands on a copy of V8.0 as there are lots of fixes regarding MAV's and particularly in our own case memory leaks.
    Its something to do with mirrored handles in the runtime.

    Shaun
    D

    [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?
    Interesting - may I ask some stupid questions?

    a) why use CLOSE WINDOW window-name instead of DESTROY window-name? What is wrong with the DESTROY verb for this, and what has it to do with the memory leaks or MAVS?
    b) why is the order of destroying objects relevant?
    c) is there a known problem with DESTROY ALL? If yes is Acu support aware and working on it?

    Keith
    D

    [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?
    Interesting - may I ask some stupid questions?

    a) why use CLOSE WINDOW window-name instead of DESTROY window-name? What is wrong with the DESTROY verb for this, and what has it to do with the memory leaks or MAVS?
    b) why is the order of destroying objects relevant?
    c) is there a known problem with DESTROY ALL? If yes is Acu support aware and working on it?

    Keith
    D

    [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?
    Interesting - may I ask some stupid questions?

    a) why use CLOSE WINDOW window-name instead of DESTROY window-name? What is wrong with the DESTROY verb for this, and what has it to do with the memory leaks or MAVS?
    b) why is the order of destroying objects relevant?
    c) is there a known problem with DESTROY ALL? If yes is Acu support aware and working on it?

    Keith
    D

    [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?
    Cannot respond to "a" or "c", but for "b", it certainly can cause problems - especially with thin client.

    I'm not sure I can answer intelligently as to why it's important, but it is. I think it has to do something with all the communication between client and server and the assigning of handles, etc. I know that Acucorp has helped us through a lot of issues with this in the past and some ECNs resulted from it. So, this may be less important now than with previous versions of AcuGT, but it's still something to keep in mind.
    D

    [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?
    Cannot respond to "a" or "c", but for "b", it certainly can cause problems - especially with thin client.

    I'm not sure I can answer intelligently as to why it's important, but it is. I think it has to do something with all the communication between client and server and the assigning of handles, etc. I know that Acucorp has helped us through a lot of issues with this in the past and some ECNs resulted from it. So, this may be less important now than with previous versions of AcuGT, but it's still something to keep in mind.
    D

    [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?
    First of all, the disclaimer: I don't know the cases behind in specifics, so albeit the general rule is as I state, it does not mean there is not exceptions and special cases that could do otherwise.
    a) Albeit they approach the task from different angles, there should be no difference. Provided both window-name are USAGE HANDLE OF WINDOW. However, if window-name in the case of the CLOSE WINDOW is a PIC X(10), there was once a bug corrupting this identifier which is now fixed.

    b) Controls may be interrelated, destroying for instance a tab control that hosts some entry fields and buttons will be making these controls "homeless". Also, there used to be some sync issues, when deleting a control, the runtime would want to move focus to another control, if this control were destroyed in the meantime but not updated centrally, it would cause the thin client to attempt a focus to a non existing control. This is another area that has been corrected.

    c) I don't know of any issue regarding DESTROY ALL in particular, but those issues mentioned under b) will have impact here as well.
    D

    [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?
    First of all, the disclaimer: I don't know the cases behind in specifics, so albeit the general rule is as I state, it does not mean there is not exceptions and special cases that could do otherwise.
    a) Albeit they approach the task from different angles, there should be no difference. Provided both window-name are USAGE HANDLE OF WINDOW. However, if window-name in the case of the CLOSE WINDOW is a PIC X(10), there was once a bug corrupting this identifier which is now fixed.

    b) Controls may be interrelated, destroying for instance a tab control that hosts some entry fields and buttons will be making these controls "homeless". Also, there used to be some sync issues, when deleting a control, the runtime would want to move focus to another control, if this control were destroyed in the meantime but not updated centrally, it would cause the thin client to attempt a focus to a non existing control. This is another area that has been corrected.

    c) I don't know of any issue regarding DESTROY ALL in particular, but those issues mentioned under b) will have impact here as well.
    D

    [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?
    Am I understanding this correctly?


    1. Are you saying that the individual controls (in a screen say) should be individually destroyed before the screen name is destroyed?

    2. If the order of destroying objects is important, would not the DESTROY ALL be expected to get the order correct?

    We have not yet used thin client but we have been seriously thinking about it. Many of the issues on the forum related to thin client do give me pause for thought - particularly about how much work we may actually have to make to the source code for thin client to work correctly (when the general belief was that there would not be any requirements other than performance issues).
    D

    [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?
    Am I understanding this correctly?


    1. Are you saying that the individual controls (in a screen say) should be individually destroyed before the screen name is destroyed?

    2. If the order of destroying objects is important, would not the DESTROY ALL be expected to get the order correct?

    We have not yet used thin client but we have been seriously thinking about it. Many of the issues on the forum related to thin client do give me pause for thought - particularly about how much work we may actually have to make to the source code for thin client to work correctly (when the general belief was that there would not be any requirements other than performance issues).
    D

    [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?
    Am I understanding this correctly?


    1. Are you saying that the individual controls (in a screen say) should be individually destroyed before the screen name is destroyed?

    2. If the order of destroying objects is important, would not the DESTROY ALL be expected to get the order correct?

    We have not yet used thin client but we have been seriously thinking about it. Many of the issues on the forum related to thin client do give me pause for thought - particularly about how much work we may actually have to make to the source code for thin client to work correctly (when the general belief was that there would not be any requirements other than performance issues).
    D

    [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: No, if you do a DESTROY ALL that should not cause problems. In fact, normally you should be able to destroy what ever you want in the order you want. But, as I said, sometimes controls are interrelated and thus, you have to pay attention.
    2: DESTROY ALL should not cause a MAV.

    Going from fat to thin client involves a lot of issues, most of them are handled automatically by the thin client, like for instance windows printing, others are semi automatic, like if you for instance use ActiveX/COM, finally some infrastructure issues like using DLLs require active participation from the programmer. The Thin Client does for instance have no way to determine the size of a structure you use with a DLL call.

    Having said all this. There have been a lot of issues regarding syncronization addressed in 7.2 and 8.0, I believe 8.0 is representing a mature product in this aspect.
    D

    [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: No, if you do a DESTROY ALL that should not cause problems. In fact, normally you should be able to destroy what ever you want in the order you want. But, as I said, sometimes controls are interrelated and thus, you have to pay attention.
    2: DESTROY ALL should not cause a MAV.

    Going from fat to thin client involves a lot of issues, most of them are handled automatically by the thin client, like for instance windows printing, others are semi automatic, like if you for instance use ActiveX/COM, finally some infrastructure issues like using DLLs require active participation from the programmer. The Thin Client does for instance have no way to determine the size of a structure you use with a DLL call.

    Having said all this. There have been a lot of issues regarding syncronization addressed in 7.2 and 8.0, I believe 8.0 is representing a mature product in this aspect.
    D

    [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?
    I agree with Gisle. Several years ago, I would've stated that thin client had a lot of exceptions and unique issues not seen when just using the runtime. However, we've been using it for years and are very pleased with how it works now. I feel as though it's a mature product now and would recommend it to anyone. This doesn't mean, however, that there are not some things to be considered before getting started.
    D

    [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?
    I agree with Gisle. Several years ago, I would've stated that thin client had a lot of exceptions and unique issues not seen when just using the runtime. However, we've been using it for years and are very pleased with how it works now. I feel as though it's a mature product now and would recommend it to anyone. This doesn't mean, however, that there are not some things to be considered before getting started.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement