I'm betting it'll be in Transaction.C .. in the destructor or the release
bit ..

On Sun, Jan 1, 2012 at 5:23 PM, Matthew Sherborne <msherbo...@gmail.com>wrote:

> So .. I used git bisect to find where it broke.
>
> I'm getting the segfault in all versions back to 3.1.11.
>
> But the failure to capture the transaction starts on this commit:
> https://github.com/kdeforche/wt/commit/7c6324bce62fc70fe27bd41985d674ec697a89e5
>
> so in summary, to reproduce, using a postgres backend, have a field in
> your table that has a unique primary key on it like:
>
> alberto_blog=# \d blog_post
>                                     Table "public.blog_post"
>   Column  |            Type             |                       Modifiers
>
>
> ----------+-----------------------------+--------------------------------------------------------
>  id       | integer                     | not null default
> nextval('blog_post_id_seq'::regclass)
>  version  | integer                     | not null
>  *name*     | text                        | not null
>  title    | text                        | not null
>  dateTime | timestamp without time zone | not null
>  body     | text                        | not null
> Indexes:
>     "blog_post_pkey" PRIMARY KEY, btree (id)
>    * "blog_post_name" UNIQUE, btree (name)*
> Referenced by:
>     TABLE "post_tag" CONSTRAINT "fk_post_tag_key2" FOREIGN KEY
> (blog_post_id) REFERENCES blog_post(id)
>
> Then have a record in the db with name 'hi' already.
>
> Then this pseudo code triggers the error:
>
> class SomeWidget : public Wt::WContainerWidget {
> private:
>    dbo::ptr<model::BlogPost> _post;
> public:
>    void save() {
>      dbo::Session s = getDbSession();
>      dbo::Transaction(s);
>      _post = new model::BlogPost();
>      _post->modify()->name = "hi";
>      try {
>       t.commit();
>      catch ( std::exception& e ) {
>       myWText->setText(e.what());
>      }
>      s.add(_post);
>      t.commit();
>   }
> };
>
> Of course the t.commit throws a Wt::Dbo::backend::PostgresExpcetion
> because of the key conflict.
>
> Pre 7c6324bce6 the exception is caught .. and next post that happens a
> segfault happens when the App dies and EditBlogPost widget dies, and tries
> to kill the _post instance. It dies calling Session::mapClass. I think the
> reason is the Session is dead at the point the widget is destroyed.
>
> Thanks guys for reading.
>
> Kind Regards,
> Matthew Sherborne
>
> On Sun, Jan 1, 2012 at 3:22 PM, Matthew Sherborne <msherbo...@gmail.com>wrote:
>
>> So I have a widget class:
>>
>> EditBlogPost
>>
>> it has a member variable:
>>
>> Wt::Dbo::ptr<model::BlogPost> _post;
>>
>> When someone hits the save button and there's a postgresql exception
>> raise (key conflict in my case):
>>
>> try {
>>   t.commit();
>> catch ( std::exception& e ) {
>>   myWText->setText(e.what());
>> }
>>
>> the exception is never caught .. the whole thread dies with:
>>
>> Warning: Wt::Dbo:Session died with 1 active objects
>>
>> if I have _post as a private member .. the next http post happens and
>> automagically segfaults trying to get session mapping or something.
>>
>> if I leave _post as a function local .. it doesn't segfault .. but still
>> my catch is never reached.
>>
>> ----
>>
>> In 3.2.0 .. the catch is reached and no evil weird errors.
>>
>>
>>
>>
>>
>>
>>
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to