[CXMLNode dealloc] EXC_BAD_ACCESS #11

Closed
runmad opened this Issue Oct 14, 2011 · 46 comments

Comments

Projects
None yet
@runmad

runmad commented Oct 14, 2011

I just switched over to ARC and I am on the feature/ARC branch. I receive an EXC_BAD_ACCESS once I am done parsing. The parsing happens inside an @autoreleasepool.

  • (void)dealloc
    {
    if (_node)
    {
    if (_node->_private == (__bridge void )self) // * EXC_BAD_ACCESS **
    _node->_private = NULL;

    if (_freeNodeOnRelease)
    {
    xmlFreeNode(_node);
    }

    _node = NULL;
    }
    //
    }

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Nov 2, 2011

Member

OK. Do you have a simple test case to reproduce this?

Member

schwa commented Nov 2, 2011

OK. Do you have a simple test case to reproduce this?

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 9, 2011

Seeing the same.

The file I'm looking at:

http://webservices.nextbus.com/service/publicXMLFeed?command=routeConfig&a=sf-muni

The code I'm using:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"sf" ofType:@"xml"];  
NSData *data = [NSData dataWithContentsOfFile:filePath];
CXMLDocument *transitParser = [[CXMLDocument alloc] initWithData:data options:0 error:nil];
NSArray *routeNodes = [transitParser nodesForXPath:@"body/route" error:nil];

mattyohe commented Dec 9, 2011

Seeing the same.

The file I'm looking at:

http://webservices.nextbus.com/service/publicXMLFeed?command=routeConfig&a=sf-muni

The code I'm using:

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"sf" ofType:@"xml"];  
NSData *data = [NSData dataWithContentsOfFile:filePath];
CXMLDocument *transitParser = [[CXMLDocument alloc] initWithData:data options:0 error:nil];
NSArray *routeNodes = [transitParser nodesForXPath:@"body/route" error:nil];
@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Dec 9, 2011

It eventually, and oddly enough just resolved itself for me. I'm also using the nextbus API.

runmad commented Dec 9, 2011

It eventually, and oddly enough just resolved itself for me. I'm also using the nextbus API.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 9, 2011

Member

I definitely want to get to the bottom of this - so the more info you guys can post the better.

If you happen to have a sample project that shows this issue that would be fantastic.

Member

schwa commented Dec 9, 2011

I definitely want to get to the bottom of this - so the more info you guys can post the better.

If you happen to have a sample project that shows this issue that would be fantastic.

@ghost ghost assigned schwa Dec 9, 2011

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Dec 9, 2011

I can't provide a sample project, since for me it just resolved itself. I honestly didn't change a thing, one day it just worked and I haven't seen the problem since.

I know the API has content-type "text/xml" for the response header, instead of application/xml, although I am not sure if this is really the problem?

runmad commented Dec 9, 2011

I can't provide a sample project, since for me it just resolved itself. I honestly didn't change a thing, one day it just worked and I haven't seen the problem since.

I know the API has content-type "text/xml" for the response header, instead of application/xml, although I am not sure if this is really the problem?

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 9, 2011

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 9, 2011

Member

Thanks. Will look into this today.

Member

schwa commented Dec 9, 2011

Thanks. Will look into this today.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 10, 2011

Member

Predictably I cannot reproduce the problem.

I did change the project to use the 5.0 deployment target (I don't have 5.1 installed yet).

I tried both on device and in simulator and couldn't reproduce the problem?

Are you certain it's crashing for you? Any other info on how to reproduce?

If you're 100% sure it crashes for you I'll install 5.1 and see if that makes any difference.

Member

schwa commented Dec 10, 2011

Predictably I cannot reproduce the problem.

I did change the project to use the 5.0 deployment target (I don't have 5.1 installed yet).

I tried both on device and in simulator and couldn't reproduce the problem?

Are you certain it's crashing for you? Any other info on how to reproduce?

If you're 100% sure it crashes for you I'll install 5.1 and see if that makes any difference.

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 10, 2011

I created that project while at work today on a machine that had 5.1 on it. It crashes in the simulator right after launch. Same problem as originally stated, EXC_BAD_ACCESS on line 53 of CXMLNode.m.

Brought that project back down when I got home just now, and I'm seeing the same on another machine with 5.0.

Just had a friend try out this project I linked above and he had the same result. I'll try to look into this some more.

I created that project while at work today on a machine that had 5.1 on it. It crashes in the simulator right after launch. Same problem as originally stated, EXC_BAD_ACCESS on line 53 of CXMLNode.m.

Brought that project back down when I got home just now, and I'm seeing the same on another machine with 5.0.

Just had a friend try out this project I linked above and he had the same result. I'll try to look into this some more.

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 11, 2011

No clue if this is related, but the top answer in this SO question is from bbum, and he points to a known ARC bug of which the fix might not be baked into the compilers we're using today. This is from August, but I don't know Apple's turnaround on pushing this into Xcode releases. I've thought about building the latest llvm to see if this still fails.

Still puzzling that you aren't seeing it though.

No clue if this is related, but the top answer in this SO question is from bbum, and he points to a known ARC bug of which the fix might not be baked into the compilers we're using today. This is from August, but I don't know Apple's turnaround on pushing this into Xcode releases. I've thought about building the latest llvm to see if this still fails.

Still puzzling that you aren't seeing it though.

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 18, 2011

Well, it seems this is not an ARC issue at all. I have just tested this against the master non-ARC branch running as a 10.7 App, and just modified the CMainController file to parse the same file as in my previous project that reproduces this error on several machines.

Here is that new project:
http://cl.ly/2l2p1r013P1A0Z1n151T

Well, it seems this is not an ARC issue at all. I have just tested this against the master non-ARC branch running as a 10.7 App, and just modified the CMainController file to parse the same file as in my previous project that reproduces this error on several machines.

Here is that new project:
http://cl.ly/2l2p1r013P1A0Z1n151T

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 18, 2011

Found something interesting. I had an old project that worked fine, but was some old checkout from when you were still on google's SVN. Either way, I found that in that previous incarnation of similar code, I autoreleased the transitParser instead of calling release later on.

If I do the same in the project I linked above and add autorelease to *transitParser, I do not seem to have the issue.

This is fine for non arc projects, but I'm not sure how I would get the same autorelease functionality in an ARC project.

Found something interesting. I had an old project that worked fine, but was some old checkout from when you were still on google's SVN. Either way, I found that in that previous incarnation of similar code, I autoreleased the transitParser instead of calling release later on.

If I do the same in the project I linked above and add autorelease to *transitParser, I do not seem to have the issue.

This is fine for non arc projects, but I'm not sure how I would get the same autorelease functionality in an ARC project.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 20, 2011

Member

I can reproduce the issue now at least. Looking.

Member

schwa commented Dec 20, 2011

I can reproduce the issue now at least. Looking.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 20, 2011

Member

So I think the problem is pretty serious and it's only by luck that it hasn't been crashing more often.

The problem seems to be that the libXML nodes created during an xpath lookup are deleted by xmlXPathFreeObject BEFORE returning to the caller.

The caller gets back an array of TouchXML nodes that each point to a libXML node. Those libXML nodes are all invalid.

This is not cool at all.

Member

schwa commented Dec 20, 2011

So I think the problem is pretty serious and it's only by luck that it hasn't been crashing more often.

The problem seems to be that the libXML nodes created during an xpath lookup are deleted by xmlXPathFreeObject BEFORE returning to the caller.

The caller gets back an array of TouchXML nodes that each point to a libXML node. Those libXML nodes are all invalid.

This is not cool at all.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 20, 2011

Member

More info…

If the nodes allocated by the xpath are dealloced before the document nodes then it all just works. Vice versa and crash.

This explains why it's so random - when things get autoreleased the dealloc order is often very indeterminate.

Member

schwa commented Dec 20, 2011

More info…

If the nodes allocated by the xpath are dealloced before the document nodes then it all just works. Vice versa and crash.

This explains why it's so random - when things get autoreleased the dealloc order is often very indeterminate.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Dec 20, 2011

Member

OK (sorry for the spam btw) I think I have a solution.

The problem was more to do with the xpath nodes getting destroyed before the xml document node was getting destroyed.

My solution:

  1. During xpath processing add the nodes to the document's nodePool.
  2. When the CXMLDocument is dealloced it iterates through the nodes in the nodePool and invalidates them - invalidation means freeing the libxml2 nodes.

This means the lifetime of all nodes is less than the lifetime of the document.

Are you folks mainly using ARC or non-ARC?

Member

schwa commented Dec 20, 2011

OK (sorry for the spam btw) I think I have a solution.

The problem was more to do with the xpath nodes getting destroyed before the xml document node was getting destroyed.

My solution:

  1. During xpath processing add the nodes to the document's nodePool.
  2. When the CXMLDocument is dealloced it iterates through the nodes in the nodePool and invalidates them - invalidation means freeing the libxml2 nodes.

This means the lifetime of all nodes is less than the lifetime of the document.

Are you folks mainly using ARC or non-ARC?

schwa added a commit that referenced this issue Dec 20, 2011

Possible fix for the #11
It seems that if you have a short lived XML document and perform an path query on the document then there's a chance (based on order of release in autorelease pool) that the xpath nodes will get freed before the document node is freed.

This causes a crash.

This fixes the issue by putting the nodes from the xpath query into the document's node pool and then explicitly freeing (via a new invalidate method) the nodes in the node pool before the document is dealloced.

schwa added a commit that referenced this issue Dec 20, 2011

Possible fix for the #11 (ARC version)
It seems that if you have a short lived XML document and perform an path query on the document then there's a chance (based on order of release in autorelease pool) that the xpath nodes will get freed before the document node is freed.

This causes a crash.

This fixes the issue by putting the nodes from the xpath query into the document's node pool and then explicitly freeing (via a new invalidate method) the nodes in the node pool before the document is dealloced.
@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Dec 20, 2011

Ah, I'm glad you're actually seeing this issue now.

Regarding ARC or non-ARC: I was using the non-ARC version and wanted to move my entire application over to ARC, so it only made sense to try out your ARC version of this. I would like to begin using it, but without this solution you've coded up, I think it would be impossible to do so. I was going to try some hackery and just run the non-ARC version inside my ARC project but with -fno-objc-arc on your code, and on some sort of adapter class that also was not running in ARC just so I could still use autorelease, but yeah... that was going to be a little much.

I will try out your fix for now.

Ah, I'm glad you're actually seeing this issue now.

Regarding ARC or non-ARC: I was using the non-ARC version and wanted to move my entire application over to ARC, so it only made sense to try out your ARC version of this. I would like to begin using it, but without this solution you've coded up, I think it would be impossible to do so. I was going to try some hackery and just run the non-ARC version inside my ARC project but with -fno-objc-arc on your code, and on some sort of adapter class that also was not running in ARC just so I could still use autorelease, but yeah... that was going to be a little much.

I will try out your fix for now.

@FrankZheng

This comment has been minimized.

Show comment Hide comment
@FrankZheng

FrankZheng Dec 23, 2011

Today, I am porting a non ARC project to an ARC one.
I download the latest ARC branch of TouchXML, then test my project, my project use xpath.
it crash at following place all the time:
CXMLDocument.m

  • (void)dealloc
    {
    ..
    xmlFreeDoc((xmlDocPtr)_node);
    }
    gdb console prints:
    malloc: *** error for object 0x684001b: pointer being freed was not allocated
    *** set a breakpoint in malloc_error_break to debug
    I have tried if don't use xpath, it won't crash.

Today, I am porting a non ARC project to an ARC one.
I download the latest ARC branch of TouchXML, then test my project, my project use xpath.
it crash at following place all the time:
CXMLDocument.m

  • (void)dealloc
    {
    ..
    xmlFreeDoc((xmlDocPtr)_node);
    }
    gdb console prints:
    malloc: *** error for object 0x684001b: pointer being freed was not allocated
    *** set a breakpoint in malloc_error_break to debug
    I have tried if don't use xpath, it won't crash.
@FrankZheng

This comment has been minimized.

Show comment Hide comment
@FrankZheng

FrankZheng Dec 23, 2011

just test the non ARC version of TouchXML
still crash at same place.
so should not related with ARC.

just test the non ARC version of TouchXML
still crash at same place.
so should not related with ARC.

@FrankZheng

This comment has been minimized.

Show comment Hide comment
@FrankZheng

FrankZheng Dec 23, 2011

I change the TouchXML to some old non ARC version used by my old project, it works fine.

I change the TouchXML to some old non ARC version used by my old project, it works fine.

@jablair

This comment has been minimized.

Show comment Hide comment
@jablair

jablair Jan 3, 2012

I was still seeing something that looked like this issue after pulling down the latest code (non-ARC version) and I did a little testing. Applying mattyohe's example to the updated library worked without crashing, but calling -[CXMLNode nodesForXPath: namespaceMappings: error:] would crash on dealloc.

Since mattyohe's example didn't go down the nodesForXPath:namespaceMappings:error code path, I tried reverting the changes to that method and the code stopped crashing on dealloc (and I saw a similar result in an ARC-ified project).

I'm not submitting a patch because I haven't done enough research to determine whether this is a valid fix, but I thought it might be a useful data point.

Here's an example against the current HEAD includes both mattyohe's test (passing) and mine (failing).

http://cl.ly/3w0s0m320Q1b1S1d2U2f

jablair commented Jan 3, 2012

I was still seeing something that looked like this issue after pulling down the latest code (non-ARC version) and I did a little testing. Applying mattyohe's example to the updated library worked without crashing, but calling -[CXMLNode nodesForXPath: namespaceMappings: error:] would crash on dealloc.

Since mattyohe's example didn't go down the nodesForXPath:namespaceMappings:error code path, I tried reverting the changes to that method and the code stopped crashing on dealloc (and I saw a similar result in an ARC-ified project).

I'm not submitting a patch because I haven't done enough research to determine whether this is a valid fix, but I thought it might be a useful data point.

Here's an example against the current HEAD includes both mattyohe's test (passing) and mine (failing).

http://cl.ly/3w0s0m320Q1b1S1d2U2f

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Jan 17, 2012

Thanks for looking into this issue.

I just pulled the fix for #11, but I am still having an issue with this bug. In CXMLNode's dealloc method, it's calling [self invalidate];

My app still crashes at the following line:

if (_node->_private == (__bridge void *)self) // EXC_BAD_ACCESS

I have cleaned, re-imported the TouchXML source but it keeps crashing when I parse.

runmad commented Jan 17, 2012

Thanks for looking into this issue.

I just pulled the fix for #11, but I am still having an issue with this bug. In CXMLNode's dealloc method, it's calling [self invalidate];

My app still crashes at the following line:

if (_node->_private == (__bridge void *)self) // EXC_BAD_ACCESS

I have cleaned, re-imported the TouchXML source but it keeps crashing when I parse.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Jan 17, 2012

Member

Any more info? Are you using xpath?

Member

schwa commented Jan 17, 2012

Any more info? Are you using xpath?

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Jan 17, 2012

Yes, using xpath.

Parsing also occurs in a asynchronous GCD queue and I am using @autoreleasepools

runmad commented Jan 17, 2012

Yes, using xpath.

Parsing also occurs in a asynchronous GCD queue and I am using @autoreleasepools

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Jan 17, 2012

Can you provide a test case project file, runmad?

Can you provide a test case project file, runmad?

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Jan 17, 2012

OK, I put together this project and was able to replicate the crash. I've pushed it to my github account:

https://github.com/runmad/iPhoneTestParser

runmad commented Jan 17, 2012

OK, I put together this project and was able to replicate the crash. I've pushed it to my github account:

https://github.com/runmad/iPhoneTestParser

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Jan 19, 2012

Member

We're back playing the cannot reproduce game… This bug is going to kill me.

Member

schwa commented Jan 19, 2012

We're back playing the cannot reproduce game… This bug is going to kill me.

@mattyohe

This comment has been minimized.

Show comment Hide comment
@mattyohe

mattyohe Jan 19, 2012

That project indeed crashes for me as well.

Maybe it's time I learn LLDB.

That project indeed crashes for me as well.

Maybe it's time I learn LLDB.

@chriseidhof

This comment has been minimized.

Show comment Hide comment
@chriseidhof

chriseidhof Jan 19, 2012

I am seeing the bug too, at

if (_node->_private == (__bridge void *)self) // EXC_BAD_ACCESS

My project is using ARC, but TouchXML is built using CocoaPods in a separate project which does not use arc. And it only crashes on certain XML files (one out of 4 I tested), but consistently.

This happens on the simulator, not sure yet what happens on the device (iPad).

Update: it only happens on the simulator for me.

I am seeing the bug too, at

if (_node->_private == (__bridge void *)self) // EXC_BAD_ACCESS

My project is using ARC, but TouchXML is built using CocoaPods in a separate project which does not use arc. And it only crashes on certain XML files (one out of 4 I tested), but consistently.

This happens on the simulator, not sure yet what happens on the device (iPad).

Update: it only happens on the simulator for me.

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Mar 12, 2012

Any updates on this bug? It's still an issue for me and I am starting to consider using another XML parser because I'll have to ship my app soon. Thanks.

runmad commented Mar 12, 2012

Any updates on this bug? It's still an issue for me and I am starting to consider using another XML parser because I'll have to ship my app soon. Thanks.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Mar 12, 2012

Member

I'm unable to spend the time on it unfortunately. I don't use TouchXML in any active projects.

If you are unable to/can't fix it yourself then moving to another XML parsing lib is probably the best thing for you.

Member

schwa commented Mar 12, 2012

I'm unable to spend the time on it unfortunately. I don't use TouchXML in any active projects.

If you are unable to/can't fix it yourself then moving to another XML parsing lib is probably the best thing for you.

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Mar 12, 2012

Alright, thanks. Any recommended XML parsing libraries these days?

runmad commented Mar 12, 2012

Alright, thanks. Any recommended XML parsing libraries these days?

@semaphore

This comment has been minimized.

Show comment Hide comment
@semaphore

semaphore Mar 15, 2012

I may have found the issue. I ran into the same problem @runmad was running into. After digging a bit I found the following code in CXMLNode_PrivateExtensions.m:103:

- (void)invalidate;
    {
    if (_node)
        {
        if (_node->_private == self)
            _node->_private = NULL;
        if (_freeNodeOnRelease)
            {
            xmlUnlinkNode(_node);//-- Fixes the malloc issue
            xmlFreeNode(_node);
            }
        _node = NULL;
        }
    }

It seems that unlinking the node before freeing it fixes the issue. I found a corresponding message on http://www.mail-archive.com/xml@gnome.org/msg08086.html which is the basis for why I tried the above fix.

Anyone else able to confirm this fix?

I may have found the issue. I ran into the same problem @runmad was running into. After digging a bit I found the following code in CXMLNode_PrivateExtensions.m:103:

- (void)invalidate;
    {
    if (_node)
        {
        if (_node->_private == self)
            _node->_private = NULL;
        if (_freeNodeOnRelease)
            {
            xmlUnlinkNode(_node);//-- Fixes the malloc issue
            xmlFreeNode(_node);
            }
        _node = NULL;
        }
    }

It seems that unlinking the node before freeing it fixes the issue. I found a corresponding message on http://www.mail-archive.com/xml@gnome.org/msg08086.html which is the basis for why I tried the above fix.

Anyone else able to confirm this fix?

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Mar 15, 2012

Member

@runmad - any word?

This would be a great thing if it fixes the problem.

Member

schwa commented Mar 15, 2012

@runmad - any word?

This would be a great thing if it fixes the problem.

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Mar 15, 2012

Alright, so I switched back to the master branch and now it parsed just fine without the xmlUnlinkNode(_node); addition. But I guess it doesn't hurt to add it?

runmad commented Mar 15, 2012

Alright, so I switched back to the master branch and now it parsed just fine without the xmlUnlinkNode(_node); addition. But I guess it doesn't hurt to add it?

@semaphore

This comment has been minimized.

Show comment Hide comment
@semaphore

semaphore Mar 15, 2012

I was getting the malloc error when releasing the CXMLDocument object. Once I added the xmlUnlinkNode(...) call, the malloc errors were gone. (All other things being equal).

I was getting the malloc error when releasing the CXMLDocument object. Once I added the xmlUnlinkNode(...) call, the malloc errors were gone. (All other things being equal).

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Mar 15, 2012

I'm using ARC for my project, so I don't control when the CXMLDocument is released. I've switched back to no-arc for TouchXML, though.

runmad commented Mar 15, 2012

I'm using ARC for my project, so I don't control when the CXMLDocument is released. I've switched back to no-arc for TouchXML, though.

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa Mar 15, 2012

Member

Well it sounds like this may be a fix - I'm really unable to help much right now… Be curious to see if it can help

Member

schwa commented Mar 15, 2012

Well it sounds like this may be a fix - I'm really unable to help much right now… Be curious to see if it can help

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad Mar 15, 2012

Yeah for sure. I'll implement it and keep an eye on it. Much rather if that was the solution instead of having to rewrite my parsing class with a new parser :) Thanks!

runmad commented Mar 15, 2012

Yeah for sure. I'll implement it and keep an eye on it. Much rather if that was the solution instead of having to rewrite my parsing class with a new parser :) Thanks!

@semaphore

This comment has been minimized.

Show comment Hide comment
@semaphore

semaphore Mar 15, 2012

(You may also want to add xmlUnlinkNode(_node) above xmlFreeDoc((xmlDocPtr)_node) in the dealloc method of CXMLDocument.m.
Like below:

- (void)dealloc
  {
  // Fix for #35 http://code.google.com/p/touchcode/issues/detail?id=35 -- clear up the node objects first (inside a pool so I _know_ they're cleared) and then freeing the document
  
  NSAutoreleasePool *thePool = [[NSAutoreleasePool alloc] init];
  
  for (CXMLNode *theNode in nodePool)
      {
          [theNode invalidate];
      }
  
  [nodePool release];
  nodePool = NULL;
  
  [thePool release];
  //
  xmlUnlinkNode(_node);//-- This fixed further malloc issues I had a bit later today :)
  xmlFreeDoc((xmlDocPtr)_node);
  _node = NULL;
  //
  [super dealloc];
  }
  

(You may also want to add xmlUnlinkNode(_node) above xmlFreeDoc((xmlDocPtr)_node) in the dealloc method of CXMLDocument.m.
Like below:

- (void)dealloc
  {
  // Fix for #35 http://code.google.com/p/touchcode/issues/detail?id=35 -- clear up the node objects first (inside a pool so I _know_ they're cleared) and then freeing the document
  
  NSAutoreleasePool *thePool = [[NSAutoreleasePool alloc] init];
  
  for (CXMLNode *theNode in nodePool)
      {
          [theNode invalidate];
      }
  
  [nodePool release];
  nodePool = NULL;
  
  [thePool release];
  //
  xmlUnlinkNode(_node);//-- This fixed further malloc issues I had a bit later today :)
  xmlFreeDoc((xmlDocPtr)_node);
  _node = NULL;
  //
  [super dealloc];
  }
  
@DaveWoodCom

This comment has been minimized.

Show comment Hide comment
@DaveWoodCom

DaveWoodCom May 2, 2012

I'm using xpath and was also getting these issues.

I can confirm that adding

xmlUnlinkNode(_node);

in the two spots mentioned above fixes the crashes I've been seeing.

I'm using xpath and was also getting these issues.

I can confirm that adding

xmlUnlinkNode(_node);

in the two spots mentioned above fixes the crashes I've been seeing.

schwa added a commit that referenced this issue May 5, 2012

Refs #11 - unlink nodes before freeing.
Conflicts:

	Source/CXMLDocument.m

schwa added a commit that referenced this issue May 5, 2012

@schwa

This comment has been minimized.

Show comment Hide comment
@schwa

schwa May 5, 2012

Member

Alright. I applied the change to both the ARC and non-ARC codebases.

I'm calling this bug closed unless someone wants to reopen.

Member

schwa commented May 5, 2012

Alright. I applied the change to both the ARC and non-ARC codebases.

I'm calling this bug closed unless someone wants to reopen.

@schwa schwa closed this May 5, 2012

@runmad

This comment has been minimized.

Show comment Hide comment
@runmad

runmad May 7, 2012

I checked out the ARC branch and ran my parse again and it crashed. So reverting back to master which worked fine and still works fine with the fix implemented. Thanks!

runmad commented May 7, 2012

I checked out the ARC branch and ran my parse again and it crashed. So reverting back to master which worked fine and still works fine with the fix implemented. Thanks!

@Deddiekoel

This comment has been minimized.

Show comment Hide comment
@Deddiekoel

Deddiekoel May 21, 2012

I am using TouchXML as part of Sudzc generated code. Because of this issue I updated TouchXML and figured I'd switch to the ARC branch. I still get the issue regularly though not preditably...

I am using TouchXML as part of Sudzc generated code. Because of this issue I updated TouchXML and figured I'd switch to the ARC branch. I still get the issue regularly though not preditably...

@ckolek

This comment has been minimized.

Show comment Hide comment
@ckolek

ckolek Sep 16, 2012

I was having the same issue with TouchXML integrated into SudzC functionality.

I modified the CXMLDocument.m file to match the non-ARC version where each node in nodePool is invalidated before the document is unlinked and freed:

- (void)dealloc
{
    // Fix for #35 http://code.google.com/p/touchcode/issues/detail?id=35 -- clear up the node objects first (inside a pool so I _know_ they're cleared) and then freeing the document

    @autoreleasepool {
        for (CXMLNode *theNode in nodePool)
        {
            [theNode invalidate];
        }

        nodePool = NULL;

    }
    //
    xmlUnlinkNode(_node);
    xmlFreeDoc((xmlDocPtr)_node);
    _node = NULL;
}

ckolek commented Sep 16, 2012

I was having the same issue with TouchXML integrated into SudzC functionality.

I modified the CXMLDocument.m file to match the non-ARC version where each node in nodePool is invalidated before the document is unlinked and freed:

- (void)dealloc
{
    // Fix for #35 http://code.google.com/p/touchcode/issues/detail?id=35 -- clear up the node objects first (inside a pool so I _know_ they're cleared) and then freeing the document

    @autoreleasepool {
        for (CXMLNode *theNode in nodePool)
        {
            [theNode invalidate];
        }

        nodePool = NULL;

    }
    //
    xmlUnlinkNode(_node);
    xmlFreeDoc((xmlDocPtr)_node);
    _node = NULL;
}
@andrewmostello

This comment has been minimized.

Show comment Hide comment
@andrewmostello

andrewmostello Jun 26, 2013

As with Deddiekoel and ckolek, I've been using TouchXML as part of the SudzC functionality, and have intermittently experienced this EXC_BAD_ACCESS crash on the simulator. It's not consistent, but once it happens, it keeps happening until some random time later when it disappears.

ckolek's fix seems to work though; thanks! Any reason why this fix wasn't pulled into the repo?

As with Deddiekoel and ckolek, I've been using TouchXML as part of the SudzC functionality, and have intermittently experienced this EXC_BAD_ACCESS crash on the simulator. It's not consistent, but once it happens, it keeps happening until some random time later when it disappears.

ckolek's fix seems to work though; thanks! Any reason why this fix wasn't pulled into the repo?

amaechler pushed a commit to amaechler/TouchXML that referenced this issue Dec 12, 2013

azeitler added a commit to doPanic/TouchXML that referenced this issue Oct 26, 2014

Update CXMLDocument.m
fix: EXC_BAD_ACCESS according to TouchCode#11 and TouchCode#37

schwa added a commit that referenced this issue Aug 10, 2016

Merge branch 'master' into develop
* master:
  CXMLNode crash fix
  Fix for compiler implicit casts warning.
  Fix for tree.h include.
  Fixed wrong libxml/HTMLparser.h include
  Added travis.
  Add a target for building as a framework
  Fixed a small leak when init-ing from a url fails due to NSData instance not being loaded.
  fix enumeration of dictionary using O( N ) algo - "enumerateKeysAndObjectsUsingBlock"
  fixed header style
  added context to libxml2 parser
  missing [super dealloc]
  Refs #11 - unlink nodes before freeing. Conflicts:
  Possibile fix for Issue #21 (calling initWithXMLString: options: error: with nil)
  Possbile fix for Issue #21 (calling initWithXMLString: options: error: with nil)
  Possible fix for the #11
  Update Source/Tidy/CTidy.m
  Update Source/Tidy/CTidy.m
  Update Source/Tidy/CTidy.h
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment