| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Uncovering Genome Mysteries
Thread: Memory management of UGM |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 5
|
|
| Author |
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1320 Status: Offline Project Badges: 
|
During the beta-test and in production too now, I got several tasks that errored out due to:
could not initialize graphics pointer in shared memory Mostly those errors occur directly after the start of the task, but also after resuming a task from last checkpoint (so LAIM off) that was running well before. E.g.: 5500 query sequences compared. 6000 query sequences compared. ERROR: could not initialize graphics pointer in shared memory. Unhandled Exception Detected... - Unhandled Exception Record - Reason: Access Violation (0xc0000005) at address 0x000000013F58FEDE write attempt to address 0x00000260 Engaging BOINC Windows Runtime Debugger... I have to convince that I'm not running the average user setup. For testing purposes and CEP2-restrictions, I'm sometimes using multiple BOINC clients on 1 machine. Before anyone comments without knowing where I'm talking about, this setup worked fine with all kinds off other BOINC projects and also with the other subprojects of WCG. It looks like UGM is accessing memory in a different way. Maybe try to cache something what's already in use by another process. |
||
|
|
armstrdj
Former World Community Grid Tech Joined: Oct 21, 2004 Post Count: 695 Status: Offline Project Badges: 
|
The issue with the shared memory segment not being able to be created is occuring in the BOINC code. When you get this error are you running multiple clients simultaneously? BOINC labels shmem with "boinc_<project_name>_N" where N is an index starting at 0. I have not tried it but I would expect mutliple clients would try to create shared memory with the same label. For example if you have 1 UGM task running on client A the shred memory is named boinc_ugm1_0 and then a UGM task is started on client B the same name is used boinc_ugm1_0. This may explain what is going on.
The issue with the science applicaitoin crashing when this occurs is a bug on our end. We will get this fixed and into testing as quickly as possible. Once the new version is available if the condition still occurs you will see the error about not being able to initialize graphics pointer in your stderr but the science app will continue to run to completion. However any instance running with this issue will not display any of the dynamic graphics elments in the graphics application. Thanks, armstrdj |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1320 Status: Offline Project Badges:
|
When you get this error are you running multiple clients simultaneously? Thanks Jonathan for answering, thinking and try to solve the issue. Yes, it only happens when I start on the same machine an ugm-task in client B, where ugm was already running in client A (no graphics running) or vice versa. It had nothing to do with running from RAM-disk, what I initially supposed. It happens too, if both clients were running with their data-dir on Harddisk. You can imagine what happens when I have 20-30 "Ready to start" or even get more tasks from the server. It only happens by the start or restart from checkpoint (so from disk and not from memory). I never had this issue with other projects, maybe cause they have the work-around/fix you plan now or they don't use the graphics. Cheers, CP |
||
|
|
armstrdj
Former World Community Grid Tech Joined: Oct 21, 2004 Post Count: 695 Status: Offline Project Badges:
|
Yes the workaround is in the other projects. We have updated the code and are testing the changes. It should be in beta later this week.
Thanks, armstrdj |
||
|
|
armstrdj
Former World Community Grid Tech Joined: Oct 21, 2004 Post Count: 695 Status: Offline Project Badges:
|
We are looking into the issue with invalids. If possible users should select the option to leave application in memory as this will minimize the problem if it is related to checkpointing. Once we find the issue we will get the fix through testing as quickly as possible.
Thanks, armstrdj |
||
|
|
|