Custom Query (981 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 981)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#48 fixed No way to undelete deleted forum threads Rytis KSMarksPsych
Description

Posted by: Date: 4:23 PM 09-07-2005 Moderators cannot undelete deleted forum threads, so if they make a mistake direct database access is needed to clear things up.

Posted by: Date: 8:40 AM 03-25-2006 This feature is part of the upcomming forum upgrade.

#49 fixed No way to move threads into another forum Rytis KSMarksPsych
Description

Posted by: Date: 9:22 PM 09-27-2005 Moderators cannot currently move threads into a more appropriate forum.

Posted by: Date: 8:40 AM 03-25-2006 This feature is part of the upcomming forum upgrade.

#53 fixed glut graphics routine problem on Linux (with s@h_enhanced/s@h) davea KSMarksPsych
Description

Posted by: Date: 2:18 PM 11-09-2005 I've been developing dynamic graphics library for setiathome_enhanced, and encountered this problem, and this looks common with public s@h and probably with Einstein@home(but I don't know its source.)

When graphics is used and X server is shut down after that, glut loses its connection to X server, causing an endless loop between restart() and xwin_graphics_event_loop() (exactly glutMainLoop()) in x_opengl.C.

But a bigger trouble happens when it finishes crunching. If it comes to the end, it causes "SIGPIPE: write on a pipe with no readerX connection to :0.0 broken (explicit kill or server shutdown)." as seen in

http://isaac.ssl.berkeley.edu/alpha/result.php?resultid=41078 (setiathome_enhanced)

this happens at the end, when no Xlib functions are supposed to be called. And note its crunching time is extremely short because I skipped crunching by editing state.sah manually. So the result must be much shorter than actual. It's not a problem at all. And I dump all the results into stderr.txt for debugging.

And in order to investigate what happens at the end of crunching, I tried to open graphics to the end (X server is always on), and surprisingly I found it caused segfault as

http://isaac.ssl.berkeley.edu/alpha/result.php?resultid=41084

It shows glut calls throttled_app_render(), which calls app_graphics_render() which causes segfault. This is very unusual, because app_graphics_render() had been running w/o problem until then.

I guess these two problems are deeply related....probably glut(or something) calls rendering procedure at the end after other graphic related procedures/structures are freed.

So I guess the iron rule is "when you shut down X server after using graphics, restart boinc, otherwise you'll get computation error."

Posted by: Date: 2:28 PM 11-09-2005 PS: sorry for abusing alpha project..:) It's too convenient for debugging....

Posted by: Date: 2:37 PM 11-09-2005 PPS: I wrote "no Xlib functions are supposed to be called" because I modified x_opengl.C so it goes to endless loop(sleep) when X connection is lost. I added XOpenDisplay() call in restart() to check available X server and if any, call XCloseDisplay() to close that temporary handler, and if not, go to endless loop. So it will never go to glMainLoop() once X server is down. So I wrote "no Xlib functions are called at the end."

Posted by: Date: 3:23 PM 11-09-2005 PPPS: This segfault doesn't happen in standalone mode. That's why I used alpha project. And SIGPIPE seems to happen in the worker thread, somehow....(I'm not confident on this one yet)

Posted by: Date: 11:35 PM 11-09-2005 Bruce, here is a crashing issue with the graphics API.

Could you all look at it?

Thanks in advance.

Posted by: Date: 11:33 PM 03-25-2006 This style of issues looks like it would be taken care of if boinc_exit called raise(getpid(), SIGKILL) instead of calling exit().

Posted by: Date: 10:31 PM 03-29-2006 Bruce - please take a look or delegate.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.