WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
95636
[EFL] Fix e_dbus_shutdown() error when exiting the Minibrowser
https://bugs.webkit.org/show_bug.cgi?id=95636
Summary
[EFL] Fix e_dbus_shutdown() error when exiting the Minibrowser
Jinwoo Song
Reported
2012-09-01 00:22:40 PDT
The destructor of BatteryProviderEfl should not call stopUpdating() because it invokes e_ukit_shutdown() even though e_ukit_init() is not called. The e_ukit_shutdown() calls the e_dbus_shutdown() and it returns error that the init is not called properly. EAPI int e_dbus_shutdown(void) { if (_edbus_init_count <= 0) { EINA_LOG_ERR("Init count not greater than 0 in shutdown."); return 0; } ... }
Attachments
patch.
(1.29 KB, patch)
2012-09-01 00:24 PDT
,
Jinwoo Song
no flags
Details
Formatted Diff
Diff
patch
(3.29 KB, patch)
2012-09-03 06:33 PDT
,
Jinwoo Song
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
patch
(3.29 KB, patch)
2012-09-03 17:41 PDT
,
Jinwoo Song
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Jinwoo Song
Comment 1
2012-09-01 00:24:51 PDT
Created
attachment 161818
[details]
patch.
Raphael Kubo da Costa (:rakuco)
Comment 2
2012-09-01 06:27:41 PDT
Comment on
attachment 161818
[details]
patch. View in context:
https://bugs.webkit.org/attachment.cgi?id=161818&action=review
> Source/WebKit2/ChangeLog:9 > + The destructor of BatteryProviderEfl should not call stopUpdating() > + because it invokes e_ukit_shutdown() even though e_ukit_init() is not called.
e_ukit_init() is called in BatteryProviderEFl::startUpdating(), so there seems to be some other problem here.
Chris Dumez
Comment 3
2012-09-01 06:37:05 PDT
Comment on
attachment 161818
[details]
patch. View in context:
https://bugs.webkit.org/attachment.cgi?id=161818&action=review
>> Source/WebKit2/ChangeLog:9 >> + because it invokes e_ukit_shutdown() even though e_ukit_init() is not called. > > e_ukit_init() is called in BatteryProviderEFl::startUpdating(), so there seems to be some other problem here.
Well, the problem is possibly that stopUpdating() is called several times?
> Source/WebKit2/UIProcess/API/efl/BatteryProvider.cpp:-55 > - m_provider.stopUpdating();
Could we maybe add a boolean property to the class to know if we are updating or not? This way we should call m_provider.stopUpdating() only we we are still updating (i.e. stopUpdating() was not explicitly called). I think this would be more reliable.
Chris Dumez
Comment 4
2012-09-01 06:41:42 PDT
Actually, the fix seems consistent with the WebKit1 implementation so OK. In addition to your fix, I would also add a check in BatteryProviderEfl::stopUpdating() / BatteryProviderEfl::startUpdating() to avoid such issue in the future. It should not cause any problem to call BatteryProviderEfl::stopUpdating() twice or BatteryProviderEfl::startUpdating() twice.
Jinwoo Song
Comment 5
2012-09-02 21:46:50 PDT
(In reply to
comment #2
)
> (From update of
attachment 161818
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=161818&action=review
> > > Source/WebKit2/ChangeLog:9 > > + The destructor of BatteryProviderEfl should not call stopUpdating() > > + because it invokes e_ukit_shutdown() even though e_ukit_init() is not called. > > e_ukit_init() is called in BatteryProviderEFl::startUpdating(), so there seems to be some other problem here.
Currently, startUpdating() is not called when the Minibrowser launches.
Jinwoo Song
Comment 6
2012-09-02 21:49:06 PDT
(In reply to
comment #4
)
> Actually, the fix seems consistent with the WebKit1 implementation so OK. > > In addition to your fix, I would also add a check in BatteryProviderEfl::stopUpdating() / BatteryProviderEfl::startUpdating() to avoid such issue in the future. It should not cause any problem to call BatteryProviderEfl::stopUpdating() twice or BatteryProviderEfl::startUpdating() twice.
I totally agree you that we need such code and would like you to add that. Thanks for your review.
Kihong Kwon
Comment 7
2012-09-02 22:21:17 PDT
(In reply to
comment #4
)
> Actually, the fix seems consistent with the WebKit1 implementation so OK. > > In addition to your fix, I would also add a check in BatteryProviderEfl::stopUpdating() / BatteryProviderEfl::startUpdating() to avoid such issue in the future. It should not cause any problem to call BatteryProviderEfl::stopUpdating() twice or BatteryProviderEfl::startUpdating() twice.
I agree with this. IMO, We need to add a flag to check for starting update.
Jinwoo Song
Comment 8
2012-09-03 06:33:03 PDT
Created
attachment 161916
[details]
patch
WebKit Review Bot
Comment 9
2012-09-03 06:36:51 PDT
Comment on
attachment 161916
[details]
patch
Attachment 161916
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/13755029
Jinwoo Song
Comment 10
2012-09-03 06:52:13 PDT
(In reply to
comment #7
)
> (In reply to
comment #4
) > > Actually, the fix seems consistent with the WebKit1 implementation so OK. > > > > In addition to your fix, I would also add a check in BatteryProviderEfl::stopUpdating() / BatteryProviderEfl::startUpdating() to avoid such issue in the future. It should not cause any problem to call BatteryProviderEfl::stopUpdating() twice or BatteryProviderEfl::startUpdating() twice. > > I agree with this. > IMO, We need to add a flag to check for starting update.
I did not add a new flag to check the updating status but used the existing one, m_timer in the BatteryProviderEfl.h. By checking if the m_timer is active or not, stopUpdating() is executed only when we are updating. Also, I added stopUpdating() in the destructor of BatteryClientEfl.cpp as we can check if we are updating or not.
Peter Beverloo (cr-android ews)
Comment 11
2012-09-03 06:52:25 PDT
Comment on
attachment 161916
[details]
patch
Attachment 161916
[details]
did not pass cr-android-ews (chromium-android): Output:
http://queues.webkit.org/results/13734463
Chris Dumez
Comment 12
2012-09-03 07:50:11 PDT
Comment on
attachment 161916
[details]
patch LGTM. Thanks, this version is much better IMHO.
Chris Dumez
Comment 13
2012-09-03 07:50:45 PDT
Why didn't you set review flag?
Jinwoo Song
Comment 14
2012-09-03 08:07:20 PDT
(In reply to
comment #13
)
> Why didn't you set review flag?
I changed the bug title to match the ChangeLog and set review flag.
Jinwoo Song
Comment 15
2012-09-03 17:41:57 PDT
Created
attachment 161951
[details]
patch
Gyuyoung Kim
Comment 16
2012-09-03 18:38:43 PDT
Comment on
attachment 161951
[details]
patch Looks fine.
WebKit Review Bot
Comment 17
2012-09-03 18:44:17 PDT
Comment on
attachment 161951
[details]
patch Clearing flags on attachment: 161951 Committed
r127436
: <
http://trac.webkit.org/changeset/127436
>
WebKit Review Bot
Comment 18
2012-09-03 18:44:22 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug