Thank you for all responses.
I was trying to compile fossil with debug enabled, but not sure, how to achieve
that. Just noted ./configure --debug, which is not what I need. May be wiki
page with some details for not experienced volunteers like me can help us to
provide more helpful feedback.
On Sat, Oct 8, 2011 at 12:01 PM, Jiri Navratil j...@navratil.cz wrote:
I was trying to compile fossil with debug enabled, but not sure, how to
achieve that. Just noted ./configure --debug, which is not what I need. May
be wiki page with some details for not experienced volunteers like me can
On Sat, Oct 8, 2011 at 12:57 PM, Stephan Beal sgb...@googlemail.com wrote:
This might help:
./configure --fossil-debug
Nevermind - that just turns on some extra SQL debugging info and one or two
other internal checks, but not something which could cause your error.
Can you please try:
gdb
Thank you.
Here we are:
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
gdb --args /Users/navratil/src/fossil/fossil sync
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered
ok, I will do that (I have to leave now for 2 hours)
--
Jiri Navratil
8. 10. 2011 v 13:31, Richard Hipp:
Breakpoint 1, 0x7fff8a1986c0 in malloc_error_break ()
(gdb) step
At this point, instead of typing step, type bt. And please send me the
result. Thanks.
On Sat, Oct 8, 2011 at 7:44 AM, Jiri Navratil j...@navratil.cz wrote:
Thank you.
Here we are:
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
gdb --args /Users/navratil/src/fossil/fossil sync
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC
Ooops. I had to discover this myself. Sorry
Please see the result now:
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
gdb --args /Users/navratil/src/fossil/fossil sync
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software
On Sat, Oct 8, 2011 at 4:24 PM, Jiri Navratil j...@navratil.cz wrote:
#9 0x0001f79e in content_get (rid=1606416160,
pBlob=0x7fff5fbff720) at content_.c:275
If i had to guess i'd say fossil's running into an endless loop while
allocating:
int *a = 0;
int mx;
Blob delta,
On Sat, Oct 08, 2011 at 04:24:45PM +0200, Jiri Navratil wrote:
Ooops. I had to discover this myself. Sorry
The memory looks totally broken. Maybe you would have to run it inside valgrind.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On Sat, Oct 8, 2011 at 4:40 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Oct 8, 2011 at 4:24 PM, Jiri Navratil j...@navratil.cz wrote:
#9 0x0001f79e in content_get (rid=1606416160,
pBlob=0x7fff5fbff720) at content_.c:275
If i had to guess i'd say fossil's running into an
Thx for replies.
I will wait for Richards response, what I have to try next.
--
Jiri Navratil, http://www.navratil.cz, +420 777 224 245
8. 10. 2011 v 16:41, Stephan Beal:
On Sat, Oct 8, 2011 at 4:40 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Oct 8, 2011 at 4:24 PM, Jiri Navratil
On Thu, Oct 06, 2011 at 06:42:07AM +0200, Jiri Navratil wrote:
I upgraded to
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
Not sure, what I shall do in gdb. So I have this. Please let me know, what
next I can trace. Sorry
fossil(2681) malloc: ***
2011/10/6 Jiri Navratil j...@navratil.cz
fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error
code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
/Users/navratil/src/fossil/fossil: out of memory
i'm going to make a huge guess
On Thu, Oct 6, 2011 at 10:36 AM, Stephan Beal sgb...@googlemail.com wrote:
bit int. However, i double that sqlite3's testing procedures would allow
such an obvious problem to slip through.
lol, that shows how embedded the word double is in my memory. It should be
doubt.
--
- stephan
On Oct 6, 2011, at 10:36 , Stephan Beal wrote:
mmap() is only used by the sqlite3 code, not fossil.
OS X uses mmap underneath when you do malloc for the large region.
--
Dmitry Chestnykh
___
fossil-users mailing list
I upgraded to
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
Not sure, what I shall do in gdb. So I have this. Please let me know, what next
I can trace. Sorry
fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error code=12)
*** error: can't allocate region
fossil sync
Server:http://myname@192.168.1.249:8098
Bytes Cards Artifacts Deltas
Sent: 648 12 0 0
Received: 898 11 0 1
Total network traffic: 573 bytes sent, 718 bytes received
fossil(25111)
On Tue, Oct 04, 2011 at 05:47:37PM +0200, Jiří Navrátil wrote:
fossil sync
Server:http://myname@192.168.1.249:8098
Bytes Cards Artifacts Deltas
Sent: 648 12 0 0
Received: 898 11 0 1
Total
2011/10/4 Jiří Navrátil j...@navratil.cz
fossil syncServer:http://myname@192.168.1.249:8098Bytes
Cards Artifacts DeltasSent: 648 12 0
0Received: 898 11 0 1Total network
traffic: 573 bytes
I just upgraded to the latest (dcc68b46b2) version of fossil, and
dutifully did fossil rebuild on all my repos.
Everything was fine, but for one repo where I get out of memory and
fossil cannot rebuild this particular repo. I also tried fossil
deconstruct followed by reconstruct, with the same
out that fossil 655e78209b also cannot rebuild this repo
Can you run the rebuild in a debugger and give me a clue as to where it is
running out of memory?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org
On 05/12/2011 02:59 PM, Richard Hipp wrote:
Can you run the rebuild in a debugger and give me a clue as to where it
is running out of memory?
Yes, I'll try to do that tonight.
Thanks,
Ron
___
fossil-users mailing list
On 05/12/2011 03:03 PM, Richard Hipp wrote:
it's just a wild guess, but does
http://www.fossil-scm.org/fossil/ci/6b382b0818 help any?
Sorry, no it doesn't.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
Here's the backtrace:
Starting program: /home/ron/proj/fossil/fossil rebuild -R rw
14.4% complete...
Breakpoint 2, fossil_malloc (n=58019464) at ./bld/main_.c:410
410 fossil_panic(out of memory);
(gdb) bt
#0 fossil_malloc (n=58019464) at ./bld/main_.c:410
#1 0x0804c5b3 in
On Thu, May 12, 2011 at 10:12 AM, Ron Aaron r...@ronware.org wrote:
Here's the backtrace:
Starting program: /home/ron/proj/fossil/fossil rebuild -R rw
14.4% complete...
Breakpoint 2, fossil_malloc (n=58019464) at ./bld/main_.c:410
410 fossil_panic(out of memory);
(gdb) bt
On Thu, May 12, 2011 at 10:41 AM, Ron Aaron r...@ronware.org wrote:
Hi --
Do you really have 58MB artifacts in your repository, or is the size
parameter going goofy on us here?
Repository Size: 62579712 bytes Number Of Artifacts: 2477 (stored as 43
full text and 2434 delta blobs)
What version of Fossil was able to rebuild this repo? Can you bisect
and figure out when it broke?
I haven't looked at what broke, but for the first time I used the
'bisect' command -- and wow, what a great tool!
Here is the output:
14253e9b3336a6292432 2010-01-09 18:32:28 BAD
On Thu, May 12, 2011 at 3:26 PM, Ron Aaron r...@ronware.org wrote:
What version of Fossil was able to rebuild this repo? Can you bisect and
figure out when it broke?
I haven't looked at what broke, but for the first time I used the 'bisect'
command -- and wow, what a great tool!
Here
It turns out I mistakenly type 'bad' instead of 'good' at some point.
After redoing the bisect I have this result:
5fc36e2faabf13e9c2c8 2010-01-13 09:58:09 BAD CURRENT
cf3809cc71ffc9557bd6 2010-01-13 09:35:46 GOOD
I manually updated to each of these versions, and verified that in fact
the one
OK, I've made another pass and am getting different results. This leads
me to believe that what I am seeing is a function of my runtime
environment, and not due to the specific builds.
My theory is that the old builds are *just* enough smaller that -- most
of the time -- they work with this
30 matches
Mail list logo
