Re: [Bug-XBoard] [bug #31634] Bad path results in segmentation fault
I believe the ~ shorthand is something that the shells expand, not
something the kernel inherently knows about. Indeed, I doubt the kernel
knows anything about something that high-level at all. But there may be
some standard function to do this translation.
Cheers,
Adrian
On Fri, Nov 12, 2010 at 2:37 PM, h.g. muller h.g.mul...@hccnet.nl wrote:
I don't think this is the correct patch.
The true problem is the *strchr(buf, '/') = 0; statement in the else part.
This assumes that in any pathname starting with ~ there will be a slash,
and causes the segfault if there is none. The patch merely diverts control
to the else part in case there happens to be a space after the ~,
but there are plenty cases with neither space nor slash, and they would
keep segfaulting.
I am a bit surprised to find this code anyway: I am not a Linux man, and
I thought that ~ was a standard filename convention handled by the kernel,
like it handles / as root. I was not aware that every application has to
make
the translation to home directory by itself. Yet this is what the code
seems
to be for.
If this code indeed has to be kept, the proper solution would be to skip
the assignment if there is no /, i.e.
{ char *p; if(p = strchr(buf, '/')) *p = 0; }
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
___
Bug-XBoard mailing list
Bug-XBoard@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-xboard
Re: [Bug-XBoard] Re: Extremely slow startup
Hello :) Thanks for the response. I did a bunch of testing and I've pinpointed the problem: it seems the call to XSync is extremely slow. On line 4568 of xboard.c if I do: printf(About to call XSync\n); XSync(xDisplay, False); printf(Done calling XSync\n); Then the About to call XSync gets printed right before the long, painful hang, and Done calling XSync gets called right when it recovers. The two prints are about 10 seconds apart. So I think this is definitely the issue. Unfortunately I'm not very familiar with low-level X programming to be able to diagnose this right away -- it's way before my time :) I'll take more of a look if nobody here knows what might be the cause off the top of their heads. Cheers, Adrian On Wed, Aug 4, 2010 at 5:53 AM, h.g. muller h.g.mul...@hccnet.nl wrote: At 22:33 3-8-2010 -0400, Adrian Petrescu wrote: Here is a strange symptom that may illuminate the issue or make it more puzzling. You decide which. This will indeed be a tough cookie... For me, startup of XBoard under Ubuntu is fast, so I cannot test it myself. It sounds like XBoard is making a system request that your system has big trouble in satisfying. What are you seeing durng these 10 seconds? Is the XBoard main window already up, and is the Chess board properly displayed? Are any of the auxiliary windows already up? The most passive mode to bring XBoard up in is -ncp (with -ics you might still hang because of connection problems with the ICS), so perhaps you should always test on that. Could you start XBoard with the -debug option? This should make a file xboard.debug, and if we are lucky, we can establish from that where it hangs. I think it does print some progress reports during the startup process, from main() in xboard.c. If not, we should add some fprintf(stderr, ...); there to figure out where it hangs. There are no time stamps with debug messages from XBoard itself, though. So to see where it hangs, it might be necessary to kill it during those 10 sec. ___ Bug-XBoard mailing list Bug-XBoard@gnu.org http://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] Extremely slow startup
Hey guys, This bug is a bit harder to define. All I know is, the latest version of Xboard from the Ubuntu repository (4.4.2-1) starts up just about instantly, takes maybe half a second. The latest xboard from master on git, however, takes a good 10 seconds on average, during which time the CPU load spikes to 100% and slows down the entire machine. After those 10 seconds it suddenly snaps back to reality and performs perfectly. However, this extremely laggy and intrusive startup is bothering me. Here are the things I've tried: - Compiling with and without Xaw3d. No difference. - Running with and without my custom xpms. No difference. - Running in and out of engine mode. No difference. The only thing that seems to make a difference is to go back to the binary shipped with Ubuntu; but I'd prefer to stay with the latest version and help with testing, etc. I've attached my .xboardrc but it looks normal to me; the only change I made is the pixmapsDirectory, but it still happens if I get rid of that too. Thanks, guys! -Adrian .xboardrc Description: Binary data ___ Bug-XBoard mailing list Bug-XBoard@gnu.org http://lists.gnu.org/mailman/listinfo/bug-xboard
[Bug-XBoard] Re: Extremely slow startup
Here is a strange symptom that may illuminate the issue or make it more puzzling. You decide which. I compiled xboard with the -pg CFLAG to build in profiling, ran it (it was slow as usual), and ran gprof on the resulting gmon.out. The result is surprising: adr...@fourier:~/Code/xboard/xboard$ head gmon.txt Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 100.00 0.02 0.023 6.67 6.67 InitPosition 0.00 0.02 0.00 5944 0.00 0.00 FileGet 0.00 0.02 0.00 638 0.00 0.00 ToLower 0.00 0.02 0.00 263 0.00 0.00 BoolFeature 0.00 0.02 0.00 192 0.00 0.00 ExpandPathName So apparently it thinks the whole thing only lasted 0.2 seconds. Normally this would imply that it's slow because it's blocking on something, and not using up actual CPU time. To confirm this I ran time on it: adr...@fourier:~/Code/xboard/xboard$ time ./xboard Loading XPMs... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 light square dark square Done. real 0m13.614s user 0m0.400s sys 0m0.396s That's quite a huge discrepancy -- 13 seconds of real time (that's accurate) but only 0.4 of those seconds were spent in the actual program. (Normally those two numbers are much closer together). At this point I'd just say the code is blocking somewhere for a very long time -- but this doesn't at all explain why the CPU goes up to 100% and slows down the entire machine during those 10 seconds. That definitely doesn't sound like idle blocking to me. The only remaining explanation is that xboard is starting up a new process while it loads. I thought it might be an engine, but again, I experience this even with -ics on. So I doubt it's that. Hopefully one of you guys knows what's going on :) Thanks! -Adrian On Tue, Aug 3, 2010 at 9:40 PM, Adrian Petrescu apetr...@gmail.com wrote: Hey guys, This bug is a bit harder to define. All I know is, the latest version of Xboard from the Ubuntu repository (4.4.2-1) starts up just about instantly, takes maybe half a second. The latest xboard from master on git, however, takes a good 10 seconds on average, during which time the CPU load spikes to 100% and slows down the entire machine. After those 10 seconds it suddenly snaps back to reality and performs perfectly. However, this extremely laggy and intrusive startup is bothering me. Here are the things I've tried: - Compiling with and without Xaw3d. No difference. - Running with and without my custom xpms. No difference. - Running in and out of engine mode. No difference. The only thing that seems to make a difference is to go back to the binary shipped with Ubuntu; but I'd prefer to stay with the latest version and help with testing, etc. I've attached my .xboardrc but it looks normal to me; the only change I made is the pixmapsDirectory, but it still happens if I get rid of that too. Thanks, guys! -Adrian ___ Bug-XBoard mailing list Bug-XBoard@gnu.org http://lists.gnu.org/mailman/listinfo/bug-xboard
