How to trace alien freed on vm side?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to trace alien freed on vm side?

EstebanLM

Hi,
I don't know if this is the right list... but as this is very low level, maybe somebody knows what is happening... :)
This is the problem (with a mac): I'm creating an external NSTableView with a proxy who handles all data source issues (yes, this is for mars).
The list looks very cool and fast, but after some time, the callback crashes the vm because it is trying to execute a method in an alien who's address is really incorrect. Let me explain a little more: I always receive a "column" parameter... as is always the same column, the address should be always the same  too. Let's say, 471403648... and then, suddenly, the column address is some 22123456789 (no matter the number, just point that is really different from the column). Of course, as the address points to nowhere, when I try to execute a method invocation with that address, I get an EXC_BAD_ACCESS, and crash.
An hypothesis is that aliens are being freed, because no "retain" or something (anyway, I tried retaining all objc objects, and nothing changes). Also, as aliens are accessed by it's pointer address, NSZombieEnabled  (to trace invocations on released objects) also does not works. So... I don't know what is happening :(

So, any idea how can I trace what happens with an alien, in the vm side?

Cheers,
Esteban

pd: yes, this is very strange, and maybe incompressible. This reflects my poor english, and even worst, my poor understanding of the problem I'm trying to solve :(
ppd: yes, today I tried randomly some vm problems... and failed to solve any of them... maybe tomorrow will be a better day :((
Reply | Threaded
Open this post in threaded view
|

Re: How to trace alien freed on vm side?

EstebanLM

Still no clue here, but there some more data:
If I check if the address is valid (< 10000000 in this case), and return a dummy value in that case, the program execution continues without problem (bad data, of course), so... is not a bad dealloc problem, maybe something when entering a callback?

btw... I'm using a 5.7.4... maybe I need to use a cog?

thanks :)
Esteban

El 01/03/2011, a las 5:51p.m., Esteban Lorenzano escribió:

> Hi,
> I don't know if this is the right list... but as this is very low level, maybe somebody knows what is happening... :)
> This is the problem (with a mac): I'm creating an external NSTableView with a proxy who handles all data source issues (yes, this is for mars).
> The list looks very cool and fast, but after some time, the callback crashes the vm because it is trying to execute a method in an alien who's address is really incorrect. Let me explain a little more: I always receive a "column" parameter... as is always the same column, the address should be always the same  too. Let's say, 471403648... and then, suddenly, the column address is some 22123456789 (no matter the number, just point that is really different from the column). Of course, as the address points to nowhere, when I try to execute a method invocation with that address, I get an EXC_BAD_ACCESS, and crash.
> An hypothesis is that aliens are being freed, because no "retain" or something (anyway, I tried retaining all objc objects, and nothing changes). Also, as aliens are accessed by it's pointer address, NSZombieEnabled  (to trace invocations on released objects) also does not works. So... I don't know what is happening :(
>
> So, any idea how can I trace what happens with an alien, in the vm side?
>
> Cheers,
> Esteban
>
> pd: yes, this is very strange, and maybe incompressible. This reflects my poor english, and even worst, my poor understanding of the problem I'm trying to solve :(
> ppd: yes, today I tried randomly some vm problems... and failed to solve any of them... maybe tomorrow will be a better day :((

Reply | Threaded
Open this post in threaded view
|

Re: How to trace alien freed on vm side?

Igor Stasenko
 
On 1 March 2011 22:59, Esteban Lorenzano <[hidden email]> wrote:
>
> Still no clue here, but there some more data:
> If I check if the address is valid (< 10000000 in this case), and return a dummy value in that case, the program execution continues without problem (bad data, of course), so... is not a bad dealloc problem, maybe something when entering a callback?
>
> btw... I'm using a 5.7.4... maybe I need to use a cog?
>

heh.. callbacks  + Alien.. Don't expect any help there. We don't have
too much people with enough expertise to be able to help with that.

I just hoping that at some day it will change. :)

> thanks :)
> Esteban


--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: How to trace alien freed on vm side?

EstebanLM

well... after a sleepless night (spent mostly watching tv, sadly), I can say this:

"looks" like callbacks, time to time, are executed twice... one with a bad arguments pointer and the subsequent correctly. I conclude this after creating a callback who returns "<<ERROR>>" as a list element (in a tableView:objectValueForTableColumn:row:), when the address is "invalid" (address >= 1000000000), and logging it... the callback is executed, and some times it answers "<<ERROR>>", but the list NEVER shows "<<ERROR>>".

is this right? no idea (yet)
if this is right... how to fix it? even less idea (yet)

best,
Esteban

El 02/03/2011, a las 6:15a.m., Igor Stasenko escribió:

>
> On 1 March 2011 22:59, Esteban Lorenzano <[hidden email]> wrote:
>>
>> Still no clue here, but there some more data:
>> If I check if the address is valid (< 10000000 in this case), and return a dummy value in that case, the program execution continues without problem (bad data, of course), so... is not a bad dealloc problem, maybe something when entering a callback?
>>
>> btw... I'm using a 5.7.4... maybe I need to use a cog?
>>
>
> heh.. callbacks  + Alien.. Don't expect any help there. We don't have
> too much people with enough expertise to be able to help with that.
>
> I just hoping that at some day it will change. :)
>
>> thanks :)
>> Esteban
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.