Re: [fossil-users] Version 1.33 - /reports failing
2015-06-02 9:22 GMT+02:00 Jan Nijtmans jan.nijtm...@gmail.com: I'm seeing the same problem in /reports. See below. However, if I remove the -O2 compiler flag from the Makefile, everything works fine. So, this could be a gcc optimization bug. It turns out not to be a gcc optimization bug after all: the optimization is very valid, the fossil code just makes an invalid assumption (that azView[] is still available after the if() , it's needed in style_footer()) Fixed here: http://fossil-scm.org/index.html/info/8184f39d803f9ad6 Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
2015-06-02 1:07 GMT+02:00 Richard Hipp d...@sqlite.org: Start in an open check-out for the repository that you want to serve. (This is not strictly necessary, but it makes things a little easier.) Then do gdb fossil. Then run test-http. You will not be prompted, but Fossil is waiting on an HTTP request. Enter GET /reports following pressing Enter twice. Note that in test-http mode, Fossil is forgiving of the HTTP request syntax and allows you to omit the HTTP/1.0 at the en dof the first line, for example. I'm seeing the same problem in /reports. See below. However, if I remove the -O2 compiler flag from the Makefile, everything works fine. So, this could be a gcc optimization bug. $ gcc --version gcc (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll see if I can trace this somewhat further, but gdb's bt shows nothing :-( Regards, Jan Nijtmans $ gdb ./fossil GNU gdb (GDB) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-pc-cygwin. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from ./fossil...done. (gdb) run test-http Starting program: ./fossil test-http [New Thread 8860.0x6d0] [New Thread 8860.0x1db0] [New Thread 8860.0x1d38] [New Thread 8860.0x2200] GET /reports 0 [main] fossil 8860 cygwin_exception::open_stackdumpfile: Dumping stack trace to fossil.exe.stackdump [Thread 8860.0x1d38 exited with code 35584] [Thread 8860.0x1db0 exited with code 35584] [Inferior 1 (process 8860) exited with code 0105400] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Standalone server slowing down significantly after long use
On 6/2/15, Philip Bennefall phi...@blastbay.com wrote: after the Fossil standalone server has been running for quite some time it becomes terribly sluggish. ... I am running on a lower end Linode VPS, but so is the sqLite repository as far as I know and I have never had any trouble with that over the four years I've been following it. The difference is probably that the https://www.sqlite.org/src site is running fossil using CGI, not as a stand-alone server. Thanks for the report. We'll poke around and try to figure out what is going wrong. Which version of Fossil did you say you were using? And did you compile it yourself? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On Jun 2, 2015, at 2:21 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: It turns out not to be a gcc optimization bug after all: the optimization is very valid According to what standard?? What I see in 30af11d4 should be legal even in C89. If you are right and azView must have function scope in order to be available on the last line it’s used in that function, version 30af11d4 shouldn’t even compile. I’m glad you found a way to placate the compiler, but brushing it off as “not an optimization bug” means GCC still has a bug waiting to bite someone else. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On Tue, Jun 02, 2015 at 11:55:39AM -0600, Warren Young wrote: On Jun 2, 2015, at 2:21 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: It turns out not to be a gcc optimization bug after all: the optimization is very valid According to what standard?? What I see in 30af11d4 should be legal even in C89. It is syntactically correct, but UB. The variable is going out of scope and the associated storage is therefore recycled. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On Tue, Jun 02, 2015 at 12:11:55PM -0600, Warren Young wrote: On Jun 2, 2015, at 12:02 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Jun 02, 2015 at 11:55:39AM -0600, Warren Young wrote: On Jun 2, 2015, at 2:21 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: It turns out not to be a gcc optimization bug after all: the optimization is very valid According to what standard?? What I see in 30af11d4 should be legal even in C89. It is syntactically correct, but UB. “Undefined Behavior”? Yes. The variable is going out of scope The patch changes only the scope of azView, so if it is out of scope, then the use on line 725 won’t compile. The only way you can refer to a variable that has gone out of scope is to pass pointers around, which isn’t going on here. No, it is exactly what is happening here via style_submenu_multichoice. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
There was a typo in my example..
But Ross Berteig gave a more clear explanation than this example.
On Tue, Jun 02, 2015 at 02:49:42PM -0400, Martin Gagnon wrote:
But here, if I'm not mistaken the problem was more like:
--
char *g_foo[2] = {NULL, NULL};
char *g_bar[2] = {hello, world};
void foo(char *p)
{
g_foo[0] = p[0]; // this point to azView
g_foo[1] = p[1]; // this point to azView
~~~^~~~ : Here should be g_bar
}
void foo2()
{
// do something with g_foo, which point to azView, which may not exist
// anymore.
}
void func(void)
{
if (some condition) {
char *azView[2];
azView[0] = g_bar[0];
azView[1] = g_bar[1];
foo(azView);
}
foo2(); // use g_foo which point to inexistent azView
}
--
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Standalone server slowing down significantly after long use
This is a hard case to reproduce as it usually takes several weeks or even a month or two, but after the Fossil standalone server has been running for quite some time it becomes terribly sluggish. You begin noticing a slower response times at first, and eventually it gets to a point where it is nearly unusable - taking 15 seconds or so to pull up the front page. As soon as I restart it, it is lightning fast again. Note that I do not restart the server machine itself - that's been running for a year or more, only the Fossil standalone server is restarted. Does anyone have any ideas why this might be happening? I am running on a lower end Linode VPS, but so is the sqLite repository as far as I know and I have never had any trouble with that over the four years I've been following it. Kind regards, Philip Bennefall ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On Jun 2, 2015, at 12:02 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Tue, Jun 02, 2015 at 11:55:39AM -0600, Warren Young wrote:
On Jun 2, 2015, at 2:21 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
It turns out not to be a gcc optimization bug after all: the optimization
is very valid
According to what standard?? What I see in 30af11d4 should be legal even in
C89.
It is syntactically correct, but UB.
“Undefined Behavior”?
The variable is going out of scope
The patch changes only the scope of azView, so if it is out of scope, then the
use on line 725 won’t compile.
The only way you can refer to a variable that has gone out of scope is to pass
pointers around, which isn’t going on here.
Classic example:
char* foo(void)
{
char bar[100];
strcpy(bar, “this won’t turn out well”);
return bar;
}
If that’s what’s going on here, this patch won’t fix it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Standalone server slowing down significantly after long use
On Jun 2, 2015, at 12:21 PM, Richard Hipp d...@sqlite.org wrote: On 6/2/15, Philip Bennefall phi...@blastbay.com wrote: after the Fossil standalone server has been running for quite some time it becomes terribly sluggish. ... I am running on a lower end Linode VPS, but so is the sqLite repository as far as I know and I have never had any trouble with that over the four years I've been following it. The difference is probably that the https://www.sqlite.org/src site is running fossil using CGI, not as a stand-alone server. You’re thinking some kind of memory leak, then? [*] That should be easy for the OP to [dis]prove, such as via top(1). For reference, my local instance is taking 0.0% of memory after running for a couple of weeks. (Meaning ~200 MiB, given that there is 6 GiB of physical RAM + 16 GiB of swap configured on this machine.) [*] I don’t mean to accuse SQLite or Fossil of completely losing track of allocated memory, but if it’s allocating chunks of memory that don’t get properly freed until the program exits, it amounts to the same thing. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On Jun 2, 2015, at 12:58 PM, Ross Berteig r...@cheshireeng.com wrote: The problem is that azView[] ...is passed in to style_submenu_multichoice() on line 744. That function preserves a copy of the pointer Okay, that makes sense. It is the sort of thing I was imagining with my foo() example, but I didn’t see anyone making copies of the pointer in my skim of the code. insert pro-GC rant here ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
Thanks for explaining this new feature. v1.33 showed a months old forgotten commit and it was easy to merge and clean up. Wasn't sure how merging such old changes would go. Thanks for Fossil! On Fri, May 29, 2015 at 10:24 PM, Doug Franklin nutdriverle...@comcast.net wrote: On 2015-05-29 19:19, Ron W wrote: I suspect, in most case, multiple independent branches with the same name are not a problem. But trunk is a special case that may warrant a warning. I don't think I'd take that suspicion to the bank. Personally, I think it should warn on duplication of an existing tag or branch name, with a --force option if you know what you're doing. :) [Grin because I hose myself most often when I'm sure I'm doing the right thing.] -- Thanks, DougF (KG4LMZ) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Standalone server slowing down significantly after long use
Thus said Philip Bennefall on Tue, 02 Jun 2015 20:12:15 +0200: This is a hard case to reproduce as it usually takes several weeks or even a month or two, but after the Fossil standalone server has been running for quite some time it becomes terribly sluggish. Has the process been reniced? How much memory does Fossil have before you restart? How many open file descriptors does it have before you restart? What journaling mode are you using? Thanks, Andy -- TAI64 timestamp: 4000556e1737 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33 - /reports failing
On 6/2/2015 12:23 PM, Joerg Sonnenberger wrote: On Tue, Jun 02, 2015 at 11:58:03AM -0700, Ross Berteig wrote: This is the class of bug that the optimizer is likely to expose, and that is difficult for tools to find. Valgrind would likely have found it, but would have to have executed a test case that attempted to generate the /reports page. Actually, this is the class of bugs that Valgrind is very *bad* at finding. msan should be able to find it, if the compiler is aggressive enough about the life-time markers. As a long time Windows user (and deeply embedded developer) I have often wished for Valgrind to be more available to me. On the rare occasions where I've been able to compile on some *nix platform too, I've been impressed by what it can find. But now that I've had my lunch and coffee, you're right. Valgrind likely can't know because it doesn't seem to have an analysis tool that actively tracks variable lifetimes to a fine enough grain. Although a suitable set of compiler de-optimizations could in principle be used to adjust the valid bits for automatics as they go in and out of scope, I don't think that has been done. In practice it would still required a test suite that exercise enough code paths and enough individual lines of code to catch this kind of thing. From a quick glance, MSan is trying to sneak up on the same problem from a different direction, and might be capable of poisoning values as they leave scope. I've never seen it before, and will make some time to learn more about it. Regardless, this kind of data lifetime bug is why I have come to really enjoy dynamic languages (like Lua and TCL). Garbage collection brings its own set of issues, but this specific bug would not have happened in a language where the lifetime of values spans from being hung on a queue by one function and removed by another. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Standalone server slowing down significantly after long use
Unfortunately I didn't check before I restarted the last time. I will keep running it, and gather statistics over time as it begins to slow down. Kind regards, Philip Bennefall On 6/2/2015 10:50 PM, Andy Bradford wrote: Thus said Philip Bennefall on Tue, 02 Jun 2015 20:12:15 +0200: This is a hard case to reproduce as it usually takes several weeks or even a month or two, but after the Fossil standalone server has been running for quite some time it becomes terribly sluggish. Has the process been reniced? How much memory does Fossil have before you restart? How many open file descriptors does it have before you restart? What journaling mode are you using? Thanks, Andy -- TAI64 timestamp: 4000556e1737 . ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33
2015-06-02 15:33 GMT+02:00 Thomas Bilk tho...@bilkfamilie.de: I managed to recreate the problem in Opensuse 13.2 maybe there is a problem there. You'll be happy to hear (I hope) that the problem has been located and it's fixed here: http://fossil-scm.org/index.html/info/8184f39d803f9ad6 Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.33
I managed to recreate the problem in Opensuse 13.2 maybe there is a
problem there. I have created a Dockerfile that sets up OpenSuse so
that fossil can be built and run. The problem is the same as on my
machine. So here is the Dockerfile:[http://pastebin.com/4tB0ZR85]
If you already have Docker installed all you need to run are these
commands in the Folder where the Dockerfile is:
docker build --tag fossil_reports_opensuse .
docker run --rm --name fossil_reports_opensuse -p 8080:8080
fossil_reports_opensuse
Then try to access the address http://{{ docker ip }}:8080/reports and
see no response.
Meanwhile I managed to build fossil in OpenSuse if I removed -O2 from
the Makefile.
On Mon, Jun 1, 2015 at 11:57 PM, Richard Hipp d...@sqlite.org wrote:
Can you offer any suggestions on how I can recreate the problem, so
that I can try to figure out what is going wrong?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
