Custom Query (981 matches)
Results (22 - 24 of 981)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#48 | fixed | No way to undelete deleted forum threads | ||
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 | ||
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) | ||
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. |