Skip to content
This repository was archived by the owner on Feb 22, 2018. It is now read-only.

RangeError in ng-repeat #1121

Closed
marc-hughes opened this issue Jun 7, 2014 · 12 comments
Closed

RangeError in ng-repeat #1121

marc-hughes opened this issue Jun 7, 2014 · 12 comments

Comments

@marc-hughes
Copy link

I get an intermittent RangeError in an ng-repeat. After it occurs, that ng-repeat stops updating for any future updates.

This is the stack trace:

RangeError: 2
STACKTRACE:
#0      List.[] (dart:core-patch/array.dart:12)
#1      NgRepeat._onChange (package:angular/directive/ng_repeat.dart:230:34)
#2      NgRepeat.expression=.<anonymous closure> (package:angular/directive/ng_repeat.dart:137:22)
#3      NgRepeat.expression=.<anonymous closure> (package:angular/directive/ng_repeat.dart:140:13)
#4      Watch.invoke (package:angular/change_detection/watch_group.dart:508:15)
#5      RootWatchGroup.detectChanges (package:angular/change_detection/watch_group.dart:450:30)
#6      RootScope.digest (package:angular/core/scope.dart:656:45)
#7      apply (package:angular/core/scope.dart:268:24)
#8      _rootRun (dart:async/zone.dart:723)
#9      _ZoneDelegate.run (dart:async/zone.dart:453)
#10     VmTurnZone._finishTurn (package:angular/core/zone.dart:150:21)
#11     VmTurnZone._onRunBase (package:angular/core/zone.dart:105:43)
#12     _onRun (package:angular/core/zone.dart:110:17)
#13     _ZoneDelegate.run (dart:async/zone.dart:453)
#14     _CustomizedZone.run (dart:async/zone.dart:663)
#15     _BaseZone.runGuarded (dart:async/zone.dart:574)
#16     _BaseZone.bindCallback.<anonymous closure> (dart:async/zone.dart:599)
#17     _createTimer.<anonymous closure> (dart:async-patch/timer_patch.dart:11)
#18     _Timer._Timer.<anonymous closure> (file:///Volumes/data/b/build/slave/dartium-mac-full-stable/build/src/dart/tools/dom/src/native_DOMImplementation.dart:530)

The exception originates in this bit of code inside NgRepeat::onChange

  changes.forEachRemoval((CollectionChangeItem removal) {                 
    var index = removal.previousIndex;    
    var row = _rows[index];
    row.scope.destroy();
    _viewPort.remove(row.view);
    leftInDom.removeAt(domLength - 1 - index);
  }); 

Specifically, index ends up being >= the length of the _rows list.

Possible fix: I added in a check for that condition and bailed out when it happens.

  changes.forEachRemoval((CollectionChangeItem removal) {                 
    var index = removal.previousIndex;
      if( index >= _rows.length ) {
        print("Would have failed (A).");
        return;
      }        
    var row = _rows[index];
    row.scope.destroy();
    _viewPort.remove(row.view);
    leftInDom.removeAt(domLength - 1 - index); 
  });

This seems to fix my problem. No more exceptions, and the display correctly updates.

I'm three days into this bug now, nothing that I've changed in the application code has helped. I've spent most of a day trying to reproduce this in a simple test app, but haven't been able to.

A little background on the app... changes to the underlying list are happening due to messages received over a real-time pubnub channel. Sometimes, several updates could come in quickly one after one another. My guess, is there is some sort of race condition happening. Like I mentioned, it's intermittent. It only happens maybe 2% of the time when I'm performing a specific action in the app.

Originally found on 0.11, also occurs in 0.12

Running as dart code in dartium 34.0.1847.0

@vicb
Copy link
Contributor

vicb commented Jun 7, 2014

Could you possibly try on master? This could be linked to a bug that was fixed in the change detection.

@mvuksano
Copy link
Contributor

@marc-hughes Cloud you also provide the html part and also describe the "specific action" (which causes the problem) in more details?

@mvuksano
Copy link
Contributor

@vicb What's the issue # you're referring to?

@matanlurey
Copy link

Helper for repro case: https://github.com/matanlurey/ng-dart-repeat-bug. Only occurs in non-checked mode and dart2js.

@vicb
Copy link
Contributor

vicb commented Jun 13, 2014

@markovuksanovic I suspect this is linked to 8dbeefc

@mvuksano
Copy link
Contributor

@vicb Yes, you're right... I did a bisect today and came to that same commit. Sorry, should have updated here.

@marc-hughes
Copy link
Author

@vicb I've been running on master since Saturday and have not experienced the bug again. Like I mentioned, it was intermittent, but I'm very hopeful since normally I would have experienced the bug several times by now.

@markovuksanovic While debugging this, I tried several variations, but even the simplest case of a div with nothing special on it caused the bug.

Here are a few I know I tried:

<worker worker="worker" ng-repeat="worker in boardCtrl.workers"></worker>
<worker worker="worker" ng-repeat="worker in boardCtrl.workers track by id"></worker>
<div ng-repeat="worker in boardCtrl.workers"></div>

The action was a drag & drop that would send a request to the server. Then in several pubnub messages back, it caused the underlying workers list to be modified. While debugging, I did try making a test case that would add/remove items in the same order, but did not experience the bug when running it.

@vicb
Copy link
Contributor

vicb commented Jun 13, 2014

If the d&d modify the subject of ng-repeat the bug was probably caused by dropping past the last item, see #1097 for details

@marc-hughes
Copy link
Author

#1097 looks very similar. Two potential differences:

I was not actually modifying anything in the d&d handler, just firing off a server call. Some time later a response (realtime/pubnub, not http) would come back which would cause a modification to the list.

The bug was occurring to me in dart/dartium code, not just in compiled js.

@vicb
Copy link
Contributor

vicb commented Jun 13, 2014

#1097 does not only occur in JS but in non-checked mode (both JS & Dart) - I realized somewhere in the middle of the thread.

This is one of the thing that made me think of this issue after @matanlurey comment.

@marc-hughes
Copy link
Author

Since moving to the master branch on June 7, I have not experienced this bug again. I believe it is fixed.

I'm not sure of your issue-closing policies.

@vicb
Copy link
Contributor

vicb commented Jun 27, 2014

let's close this - reopen if you experience the defect again

@vicb vicb closed this as completed Jun 27, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

4 participants