Re: [Monotone-devel] nvm.experiment.database-management
Thomas Keller m...@thomaskeller.biz writes: Am 18.05.2010 14:41, schrieb Thomas Keller: Am 18.05.2010 14:07, schrieb Thomas Keller: Am 18.05.2010 13:46, schrieb Stephen Leake: Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. This is the problem when I just copy over the existing code and don't think for myself - the issue was the reference to the shared_ptr in the database constructor which rendered the reference counting of shared_ptr useless. I changed that in 35cfbc0b277b7c0a5e3a401688078cee11dc20ad and mtn no longer crashes for me. Can you confirm that? Forget this fix - Well, it did fix the crash. For me. it won't cache database_impl instances at all. I don't see why not; can you explain? I'll look further into the issue tonight. Ok. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.experiment.database-management
I've looked thru the log of nvm.experiment.database-management, and the changes make sense, although I'm not clear how they all relate to the issue of searching for a database on a path. It's currently crashing in the database-impl deconstructor. Part of the point of Boost is you're not supposed to be able to get a crash from a deconstructor; congratulations :). Compiling with -O0 gives a better stack trace; the actual crash is in Botan. I suspect something is being deconstructed twice, which is often a bad idea, although deconstructors should be designed to handle that. But I don't see a double invocation in the debugger. Perhaps this is one reason the dbcache was a member of the application class? I'm off to work now; I'll look at this some more later. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 13:46, schrieb Stephen Leake: I've looked thru the log of nvm.experiment.database-management, and the changes make sense, although I'm not clear how they all relate to the issue of searching for a database on a path. The problem was that I stumbled across many limitations during the implementation and fixed them on the way - f.e. I needed to retrieve the branch option from _MTN/options, but there was only a get_database_option() in work.cc. Adding another get_branch_option() looked too stupid, so I changed the code overall... :) Pretty much the same with the database code; I wanted to be able to create a local, throw-away database instance without giving it a sense of app_state, but to achieve that the random number generator and the db implementation cache had to be moved. I thought this was a good change because we have the long-term goal of getting rid of app_state anyways. It's currently crashing in the database-impl deconstructor. Part of the point of Boost is you're not supposed to be able to get a crash from a deconstructor; congratulations :). Hehe, yes. Compiling with -O0 gives a better stack trace; the actual crash is in Botan. I suspect something is being deconstructed twice, which is often a bad idea, although deconstructors should be designed to handle that. But I don't see a double invocation in the debugger. Yeah, I saw the crash in botan as well - maybe this is related to the rng change I did on my way. Derek proposed to wrap the instance in a shared pointer, but I'm unsure if this helps at all, because we have to explicitely give the raw pointer away to Botan later anyways. Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. Thanks for looking! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 14:07, schrieb Thomas Keller: Am 18.05.2010 13:46, schrieb Stephen Leake: Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. This is the problem when I just copy over the existing code and don't think for myself - the issue was the reference to the shared_ptr in the database constructor which rendered the reference counting of shared_ptr useless. I changed that in 35cfbc0b277b7c0a5e3a401688078cee11dc20ad and mtn no longer crashes for me. Can you confirm that? Thanks, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.database-management
Am 18.05.2010 14:41, schrieb Thomas Keller: Am 18.05.2010 14:07, schrieb Thomas Keller: Am 18.05.2010 13:46, schrieb Stephen Leake: Perhaps this is one reason the dbcache was a member of the application class? Well, it should not - unless its considered bad practise to store shared_ptr's in a static map - I found a couple of references with similar problems, but no quick explanation or solution. I need to investigate this further. This is the problem when I just copy over the existing code and don't think for myself - the issue was the reference to the shared_ptr in the database constructor which rendered the reference counting of shared_ptr useless. I changed that in 35cfbc0b277b7c0a5e3a401688078cee11dc20ad and mtn no longer crashes for me. Can you confirm that? Forget this fix - it won't cache database_impl instances at all. I'll look further into the issue tonight. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
