You are not allowed to make most EFL calls outside of the main thread.
Watch out if you have more.
--
Tom.
On Sat, Aug 29, 2015 at 11:54 PM, Andrew Williams
wrote:
> Hi,
>
> Turned out to be lack of locking - some Eo calls were being made outwith
> the main_thread context - helgrind found it pr
Hi,
Turned out to be lack of locking - some Eo calls were being made outwith
the main_thread context - helgrind found it pretty fast.
Thanks for all the help,
Andrew
On Tue, 11 Aug 2015 19:58 Andrew Williams wrote:
> Hi JackDanielZ
>
> Thanks for looking into this, I appreciate the help. I thi
Hi JackDanielZ
Thanks for looking into this, I appreciate the help. I think you're seeing
this other bug: https://phab.enlightenment.org/T2136
I have no idea yet why this is being freed but I have noticed that the
widget sometimes disappears before crash which I guess means something is
actually
Hi Andy,
I installed and tried. A few times work well for me. Many many switches make
the job. However I have an issue with gdb, as bt contains more than 1800 frames
(http://pastebin.com/L34yR7b7) :-)))
For some reason, someone unrefs some object during its destruction, leading to
some Eo erro
Hi,
Yeah it's weird. I suspect it may be non-deterministic which might explain
the behavior when debugging.
The editor->entry looks to have the same pointer value as when the entry
widget is created.
To reproduce open a few files in edi (make sure you've built with libclang
so syntax highlighting
Hi Andrew,
This is really weird that that eo_class_name_get crashes when
eo_class_name_get(eo_class_get()) doesn't.
What is the value of the editor->entry?
Can you send us instructions on how to reproduce it locally?
JackDanielZ
On Fri, 07 Aug 2015 13:30:33 +
Andrew Williams wrote:
> Hi
Hi,
>From what I can tell the widget has been freed by elm/evas in a smart_del
callback and so removed from the lookups.
Currently I have no idea why as the widget is still on screen.
Looking further...
Andrew
On Fri, 7 Aug 2015 at 09:59 Tom Hacohen wrote:
> On 06/08/15 23:27, Andrew Williams
On 06/08/15 23:27, Andrew Williams wrote:
> Hi guys,
>
> Thanks for the help - still rather confuse though - no more info as far
> as I can see...
>
> (gdb) p eo_data_scope_get(editor->entry, elm_code_widget_class_get())
> $3 = (void *) 0x0
> (gdb) p eo_class_name_get(eo_class_get(editor->entry))
>
Hi guys,
Thanks for the help - still rather confuse though - no more info as far as
I can see...
(gdb) p eo_data_scope_get(editor->entry, elm_code_widget_class_get())
$3 = (void *) 0x0
(gdb) p eo_class_name_get(eo_class_get(editor->entry))
$4 = 0x0
(gdb) p eo_class_name_get(editor->entry)
Progra
On 22/07/15 08:52, Daniel Zaoui wrote:
> London in September -> rainy -> depression -> drink to forget -> weak and
> grumpy -> miss planes, trains and commits
Joke's on you. I'm never weak, and I've never missed a train.
--
Tom.
>
> I don't see any other logic reason :P
>
> On Wed, 22 Jul 2015
London in September -> rainy -> depression -> drink to forget -> weak and
grumpy -> miss planes, trains and commits
I don't see any other logic reason :P
On Wed, 22 Jul 2015 08:35:04 +0100
Tom Hacohen wrote:
> On 22/07/15 08:31, Tom Hacohen wrote:
> > When was that changed? Isn't it kinda wron
On Wed, 22 Jul 2015 08:31:35 +0100
Tom Hacohen wrote:
According to git, Jeremy did that two years ago.
Personally, I like it this way as it is easier for debugging. And well, I never
needed to get the name of a class, but always of an object.
> When was that changed? Isn't it kinda wrong to do
On 22/07/15 08:31, Tom Hacohen wrote:
> When was that changed? Isn't it kinda wrong to do it now that both Eo
> classes and objects are "Eo *"? Because when you invoke this on classes
> you want to get the class class, how do you do the detection? Feels a
> bit inconsistent to me.
>
Two years ago.
When was that changed? Isn't it kinda wrong to do it now that both Eo
classes and objects are "Eo *"? Because when you invoke this on classes
you want to get the class class, how do you do the detection? Feels a
bit inconsistent to me.
--
Tom.
On 22/07/15 08:28, Daniel Zaoui wrote:
> On Wed,
On Wed, 22 Jul 2015 08:21:02 +0100
Tom Hacohen wrote:
Hey boy, you don't need anymore eo_class_get in the middle! ;-)
> p eo_class_name_get(eo_class_get(editory->entry))
>
> As Daniel said though, this shouldn't and can't happen. The only
> reason why this function would return NULL is an error
p eo_class_name_get(eo_class_get(editory->entry))
As Daniel said though, this shouldn't and can't happen. The only reason
why this function would return NULL is an error. It works by adding an
offset to the data pointer, so as long as it passes (basic) validation,
it should at least return some
Hi,
I never saw this kind of behavior, except if your object has been freed (should
see error prints) or your pointer is NULL or even if your object is not of the
correct type.
Do you see any Eo error messages? Can you "p eo_class_name_get(editor->entry)"?
Can you enter the function and give mo
Hi,
I'm trying to trace down a really annoying bug but it's proving illusive.
I have some Eo objects (the Elm_Code_Widget) that stores a lot of
information in it's associated data object. This works most of the time but
on some occasions - potentially in the vicinity of different thread access,
bu
18 matches
Mail list logo
