MemoryError: std::bad_alloc

[djouallah]

What happens?

MemoryError: std::bad_alloc

To Reproduce

colab notebook
https://colab.research.google.com/drive/1d5dFivmfnTWe-F8ecTcpLugtHax0beSG#scrollTo=0cUOn8QbPBv1

OS:

linux

DuckDB Version:

0.10.3.dev773

DuckDB Client:

Python

Full Name:

mim

Affiliation:

personal

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a nightly build

Did you include all relevant data sets for reproducing the issue?

Yes

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have

[szarnyasg]

Hi @djouallah, thanks for raising this issue. When trying to run the reproduction script, I get a NotImplementedException:

---------------------------------------------------------------------------
NotImplementedException                   Traceback (most recent call last)
[<ipython-input-3-3af29e6fae21>](https://localhost:8080/#) in <cell line: 36>()
     34 on x.duid=z.duid """).to_view('DUID_WA')
     35 
---> 36 df_duid=duckdb.sql(f""" with xx as (select * from DUID union BY NAME select * from DUID_WA)
     37               select trim(DUID) as DUID,min(Region) as Region, min(FuelSourceDescriptor) as FuelSourceDescriptor,min(Participant) as Participant from xx group by all
     38               """)

[/usr/local/lib/python3.10/dist-packages/duckdb/__init__.py](https://localhost:8080/#) in sql(query, **kwargs)
    453     else:
    454         conn = duckdb.connect(":default:")
--> 455     return conn.sql(query, **kwargs)
    456 _exported_symbols.append('sql')
    457 

NotImplementedException: Not implemented Error: Enum value: '6' not implemented

Can you please take a look?

[djouallah]

the first run on colab, crash the notebook. the second run you get this

[szarnyasg]

Hi, I ran it and got a slightly different error. This may be traced to the same underlying issue so I'm marking this as reproduced and we'll take a look.

---------------------------------------------------------------------------
InternalException                         Traceback (most recent call last)
[<ipython-input-1-3af29e6fae21>](https://localhost:8080/#) in <cell line: 36>()
     34 on x.duid=z.duid """).to_view('DUID_WA')
     35 
---> 36 df_duid=duckdb.sql(f""" with xx as (select * from DUID union BY NAME select * from DUID_WA)
     37               select trim(DUID) as DUID,min(Region) as Region, min(FuelSourceDescriptor) as FuelSourceDescriptor,min(Participant) as Participant from xx group by all
     38               """)

[/usr/local/lib/python3.10/dist-packages/duckdb/__init__.py](https://localhost:8080/#) in sql(query, **kwargs)
    453     else:
    454         conn = duckdb.connect(":default:")
--> 455     return conn.sql(query, **kwargs)
    456 _exported_symbols.append('sql')
    457 

InternalException: INTERNAL Error: Attempted to access index 0 within vector of size 0
This error signals an assertion failure within DuckDB. This usually occurs due to unexpected conditions or errors in the program's logic.
For more information, see https://duckdb.org/docs/dev/internal_errors

[lnkuiper]

I managed to reproduce this locally, using the python bleeding edge. However, when I build the python package locally (in debug mode, because we need symbols) it doesn't reproduce. Maybe it has been fixed, or it only shows up in release builds. This needs some more investigation

[djouallah]

now, I am getting a different error

InternalException: INTERNAL Error: Attempted to access index 0 within vector of size 0
This error signals an assertion failure within DuckDB. This usually occurs due to unexpected conditions or errors in the program's logic.
For more information, see https://duckdb.org/docs/dev/internal_errors

[djouallah]

I would really appreciate not releasing 0.10.3 till this is fixed :) please

[Tishj]

Thanks for raising this, but in the future, please put more effort into reducing the issue
It looks very esoteric and hard to run into in your reproduction

Spatial is not needed to reproduce this issue, removing that from the repro would have made this a much bigger dot on our radar

This is the only code needed to reproduce the problem.
Had I seen this, it would have been a bigger priority to tackle

import duckdb

duckdb.sql("""
	create table tbl(a varchar);
	insert into tbl values ('test');
	SELECT
		*
	FROM tbl
""").to_view('DUID')

res = duckdb.sql("select * from DUID").fetchone()
print(res)