BUG: refs not set when creating DataFrame from Series/Index with StringDtype

[kjmin622]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
from pandas import DataFrame, Series, Index
import pandas._testing as tm
from pandas.tests.copy_view.util import get_array

with pd.option_context("infer_string", False):
    obj = Series(["a", "b"], dtype="str")
    df = DataFrame(obj, dtype="str")

    assert tm.shares_memory(get_array(obj), get_array(df, 0))  # OK
    assert not df._mgr._has_no_reference(0)  # AssertionError

Issue Description

When creating a DataFrame from a Series or Index with dtype="str" via DataFrame(obj, dtype="str"), the underlying memory is shared with the source, but the copy-on-write reference (refs) is not passed to the block. As a result, df._mgr._has_no_reference(0) returns True even though the block is shared, so the CoW reference tracking is wrong. Other dtypes (e.g. int64, object) set refs correctly in the same situation.

Expected Behavior

When the DataFrame shares memory with the source Series/Index, refs should be set so that _has_no_reference(0) is False.

obj = Series(["a", "b"], dtype="str")
df = DataFrame(obj, dtype="str")

assert tm.shares_memory(get_array(obj), get_array(df, 0))
assert not df._mgr._has_no_reference(0) # refs present → CoW can trigger correctly

Installed Versions

INSTALLED VERSIONS

commit : 366ccdf
python : 3.13.7
python-bits : 64
OS : Windows
OS-release : 11
Version : 10.0.26200
machine : AMD64
processor : Intel64 Family 6 Model 151 Stepping 2, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : Korean_Korea.949

pandas : 3.0.0
numpy : 2.4.1
dateutil : 2.9.0.post0
pip : 25.2
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : None
lxml.etree : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : 3.1.5
psycopg2 : None
pymysql : None
pyarrow : 22.0.0
pyiceberg : None
pyreadstat : None
pytest : 9.0.2
python-calamine : None
pytz : 2025.2
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
qtpy : None
pyqt5 : None

[kjmin622]

This issue fixes a part of the code that was consistently causing a specific PR unit test to fail. (Unit Tests / PANDAS_FUTURE_INFER_STRING=0 (pull_request))

In _form_blocks (in managers.py), the consolidated path for 1d-only extension dtypes (e.g. StringDtype) created blocks without passing the refs list, unlike the non-consolidated path.

For the is_1d_only_ea_dtype branch in _form_blocks, blocks are now created via new_block_2d(..., refs=refs[x[0]]) so that the refs from _homogenize are passed through. This restores correct ref tracking when building a DataFrame from a Series/Index with string dtype (and other 1d-only EAs) so that _has_no_reference(0) is False when memory is shared.

[rhshadrach]

@kjmin622 - I'm not seeing an AssertionError on main with the example in the OP. Can you confirm if you're seeing this on the main branch?

[kjmin622]

@rhshadrach There was an additional condition for this issue. The issue only occurred when PANDAS_FUTURE_INFER_STRING=0 was set. This corresponds to Unit Tests / PANDAS_FUTURE_INFER_STRING=0, which currently fails in all PRs.

[rhshadrach]

Thanks @kjmin622 - I've updated the reproducer in the OP to include this.

[jorisvandenbossche]

It is relevant to mention that this issue is the failing test on CI right now. Temporarily xfailing it in #64024