Tested again, if I run this I dont get any changes on toggling editmode on the armature.
---
for b in bpy.context.active_object.pose.bones:
while b.constraints: b.constraints.remove(b.constraints[0])
---

Good if someone else can test this.

tagged as *NEEDS VERIFICATION*, since it works ok for me, need someone else to test.

tracked down the bone that seems to be the culprit;

DEF_rear_upper_leg_mid.b.l -- the first vertical bone up the chain from the selected one

and the ones further down the chain from them.

The roll goes from -180 to -179.93 (-3.140290 from ctrl-C for some odd reason) after a couple times toggling into edit mode. Another oddity is if I set the roll to 180 it gets converted to -180... which I suppose is the same thing.

This bone's parent isn't effected (roll = 0) and there aren't any constraints anywhere near them to make a difference.

On my system toggling editmode gives a consistent -179.93 value for this bone.

Been trying to track down what the problem is.

So far I figured out:
* It doesn't effect all bones
* Only seems to happen to bones that have a roll of ~180
* If you un-parent the bone the problem stops

I have also been able to get it to happen in a new file after doing a 'scale x, -1. (which also seems to have messed up roll values) but even that is random.

Could be a 32 bit rounding error -- I messed with the value change for the other fix to the bone roll issue and it would still happen just not as badly (or worse, don't quite remember).

Confirmed, on Ubuntu 64bit, there is a change. I get the value -3.141266 (-179.98) when I first load the file, followed by (-179.96) -3.140940 after the first toggle.
to reproduce, select the bone in pose mode, tab in, copy the value or just observe it, and toggle again, the number does change by .02. typing in 180 flips to -180. It appears there is some accuracy issue.. as far as I know , constraints in pose mode should have no way of affecting edit mode roll.
I've suspected stuff like this every now and then - since I use rigamarule I am currently 'immune' since I have code to easily reset my rolls if they are critical.

That bone consistently sticks to -179.93 for me, tab in out many times.

I can reproduce the problem, starts at -179.98 and stabilizes at -179.93 (Mac debug build).

I'm not really surprised this happens given the way this works, it's an old issue, it constantly converts between the two different representations, with floating point imprecision this is expected. Also, 180 is equivalent to -180 as far as roll is concerned.

The code can be made smarter, so that it detects if no rotations changed and preserve the values, and/or compare old/new roll and do +/- 360 degrees to get it as similar as possible to the previous value. But as far as I'm concerned this is a "known issue".

Same behaviour as noted by Brecht observed here (Vista + msvc/scons).

I probably won't get around to fixing this anytime soon, so unassigning from self for now.

closing duplicate
[#24889] Incremental offset in bone when entering and exiting edit mode
includes useful test file which shows the bug in a more simple example.

The only solution I can think of is to recode this with double precision. I tried that already for some of the calls without luck. Needs bigger revisions here.

Added on our todo here:
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Armature

If I may add a comment (this just bit me again, I've lost count how many times): I've added py code to my rigs to basically reset the rolls to 'sane' values. IMO the main problem is recalculating the roll when you enter edit mode. This value should just be stored and calculated one way (edit-> pose mode) and not the other. Then there would be no accumulation of errors, and no instability.
In other words, this is a cyclic dependency within the blender code ;)
So can't we just store the roll in the bones/pose bones, and then copy them back to the edit bones? this would avoid the error alltogether.