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] 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
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] 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] 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] Version 1.33 - /reports failing
Jooks like this never made it to the list when it was sent on May 28th. In message 20150528165652.GA2489@k8, Svyatoslav Mishyn writes: (Wed, 27 May 14:03) Warren Young: On May 23, 2015, at 1:25 PM, Svyatoslav Mishyn j...@openmailbox.org wrote: /tmp: wget -S http://localhost:8080/reports --2015-05-23 21:42:12-- http://localhost:8080/reports Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:8080... connected. HTTP request sent, awaiting response... No data received. Retrying. That works here. It doesn't for me. Finally, I found why ;) It is just CFLAGS=' -O2'. I also have the /reports url crashing with no output. Recompiling after changing the top level Makefile to remove -O2 from the TCCFLAGS makes /reports work. The side effect is to turn off optimization which isn't great. This is on Linux mint 17.1 with gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) GNU ld (GNU Binutils for Ubuntu) 2.24 Is there a way to run fossil under gdb in single shot mode where it will listen at a port but not fork a child to handle the request. That would make debugging this a lot easier rather than trying to chase across a forking process. echo 'GET /fossil/reports HTTP/1.1' | fossil http ~/fossil_repos/ | less is the right idea, but echo 'GET /fossil/reports HTTP/1.1' | gdb fossil sends the get to gdb and not to fossil so Also is there any logging in fossil thatt I can enable to help debug where things are actually going wrong? -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. ___ 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/1/15, John P. Rouillard rouilj+fos...@cs.umb.edu wrote: Jooks like this never made it to the list when it was sent on May 28th. Is there a way to run fossil under gdb in single shot mode where it will listen at a port but not fork a child to handle the request. Yes. 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. -- 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
