Common bugs from reference sharing in C Sharp (C#) - Step-by-Step Execution

Concept Flow - Common bugs from reference sharing

Create Object A

↓

Assign Reference to B

↓

Modify Object via B

↓

Check Object via A

↓

See Changes Reflect in A

↓

Unexpected shared state bug

When two variables share a reference to the same object, changes through one affect the other, causing unexpected bugs.

Execution Sample

C Sharp (C#)

using System;
using System.Collections.Generic;

class Program {
  static void Main() {
    var listA = new List<int> {1, 2};
    var listB = listA;
    listB.Add(3);
    Console.WriteLine(string.Join(",", listA));
  }
}

This code shows how modifying listB also changes listA because both reference the same list object.

Execution Table

Step	Action	listA Contents	listB Contents	Explanation
1	Create listA with [1, 2]	[1, 2]	null	listA points to a new list with 1 and 2
2	Assign listB = listA	[1, 2]	[1, 2]	listB now references the same list as listA
3	Add 3 to listB	[1, 2, 3]	[1, 2, 3]	Adding 3 via listB changes the shared list
4	Print listA	[1, 2, 3]	[1, 2, 3]	listA shows the change because it shares the list
5	End	[1, 2, 3]	[1, 2, 3]	Execution ends with both variables referencing the same modified list

💡 Execution stops after printing listA which reflects changes made through listB due to shared reference.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
listA	null	[1, 2]	[1, 2, 3]	[1, 2, 3]
listB	null	[1, 2]	[1, 2, 3]	[1, 2, 3]

Key Moments - 3 Insights

Why does changing listB also change listA?

Because listB and listA both point to the same list object in memory, so modifying one affects the other (see execution_table step 3).

Is listB a copy of listA after assignment?

No, listB is just another reference to the same list object, not a separate copy (see execution_table step 2).

How can we avoid this shared reference bug?

Create a new copy of the list instead of assigning the reference, so changes to one list don't affect the other.

Visual Quiz - 3 Questions

Look at the execution_table, what is the content of listA after step 3?

A [1, 2, 3]

B [1, 2]

C [3]

D null

💡 Hint

Check the 'listA Contents' column at step 3 in the execution_table.

At which step do listA and listB start referencing the same object?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Action' column in execution_table where listB is assigned listA.

If we want listB to be independent of listA, what should we do?

A Assign listB = listA

B Create a new list and copy elements from listA to listB

C Modify listA after assigning listB

D Do nothing, shared references are fine

💡 Hint

Refer to key_moments about avoiding shared reference bugs.

Concept Snapshot

Common bugs from reference sharing:
- Assigning one variable to another copies the reference, not the object.
- Changes via one reference affect all references to that object.
- To avoid bugs, create a copy of the object instead of sharing references.
- Example: listB = new List<int>(listA) creates a copy in C#.

Full Transcript

This example shows how assigning one variable to another copies the reference to the same object, not the object itself. When listB is assigned listA, both point to the same list. Adding an element to listB changes the list seen by listA. This causes bugs if you expect independent lists. To avoid this, create a new copy of the list instead of sharing references. The execution table traces each step, showing how listA and listB contents change together. Key moments clarify why changes affect both variables and how to prevent this bug.