php segmentation fault when connecting to Access database

[raphael75]

I have Ubuntu 24.04 and php 8.3. I'm trying to connect to an Access DB through PDO ODBC running on the command line. Here is what I have enabled:

$ php -i | grep PDO 
PDO 
PDO support => enabled 
PDO drivers => mysql, odbc 
PDO Driver for MySQL => enabled 
PDO_ODBC 
PDO Driver for ODBC (unixODBC) => enabled

code:

<?php 
$access_file = './myfile.mdb'; 
$db=new PDO('odbc:Driver=MDBTools; DBQ=' . $access_file . ';'); 
?>

error:

Segmentation fault (core dumped)

That's all I get, no other information. I am able to connect to and run queries on this mdb file with DBeaver, so the file should be ok. I haven't been able to find what would cause a Segmentation fault just by creating the PDO connection.

I tried mdbtools. If I run the mdb-ver it returns "JET4". If I run mdb-sql I can run queries and they return correctly. I also tried "describe table" and it worked correctly, too. So it looks like everything is working correctly with the mdbtools.

I found some old .mdb files that I created years ago for an Access class. I was able to load and run queries on them in DBeaver and work with them using mdb-tools, but again I get the Segmentation fault with them when trying to open them with PHP. It seems to be something specific to PHP.

[requinix]

Can you post a backtrace from gdb?

[Random8]

Would you not need to use the full file path for $access_file?

[raphael75]

@requinix I have never used gdb before, but I just went through a tutorial on how to use it with php and here is the output. Please let me know if this is what you need:

(gdb) run myfile.php /f:"out/data__2025-05-04__22.12.12.json"
Starting program: /usr/bin/php myfile.php /f:"out/data__2025-05-04__22.12.12.json"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libtinfo.so.6
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd1970) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428
warning: 428    /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c: No such file or directory

@Random8 I tried using the full file path and got the same error.

[requinix]

5 hours ago, raphael75 said:

@requinix I have never used gdb before, but I just went through a tutorial on how to use it with php and here is the output. Please let me know if this is what you need:

Almost there. Do that, then when you get the gdb prompt enter "bt" and it will dump a bunch of numbered lines.

So far, though, it looks like the problem is in unixODBC, which is surprising as you're already on the current version - that said, it's been a couple years so I'm not sure it's still maintained...

[raphael75]

Here you go:

(gdb) run myfile.php /f:"out/data__2025-05-04__22.12.12.json"
Starting program: /usr/bin/php myfile.php /f:"out/data__2025-05-04__22.12.12.json"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libtinfo.so.6
Program received signal SIGSEGV, Segmentation fault.
Downloading source file /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c
0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd19c0) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428                
warning: 428    /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c: No such file or directory
(gdb) bt
#0  0x00007ffff29ec0cd in CLDisconnect (connection_handle=0x555555dd19c0) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/cur/SQLConnect.c:428
#1  0x00007ffff2b9274b in close_pooled_connection (ptr=0x555555dd2f80) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLConnect.c:2916
#2  0x00007ffff2b9eb9a in __strip_from_pool (env=0x555555d3f630) at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLConnect.c:3101
#3  __SQLFreeHandle (handle_type=<optimized out>, handle=0x555555d3f630)
    at /build/unixodbc-WNgXyL/unixodbc-2.3.12/DriverManager/SQLFreeHandle.c:283
#4  0x00007ffff2cecfd6 in ?? () from /usr/lib/php/20230831/pdo_odbc.so
#5  0x00007ffff71adb80 in ?? () from /usr/lib/php/20230831/pdo.so
#6  0x0000555555909a3f in zend_objects_store_del ()
#7  0x0000555555881a8e in zend_hash_reverse_apply ()
#8  0x000055555585b5ed in ?? ()
#9  0x000055555586cdbd in zend_call_destructors ()
#10 0x00005555557fdaed in php_request_shutdown ()
#11 0x000055555595f249 in ?? ()
#12 0x0000555555684791 in ?? ()
#13 0x00007ffff722a1ca in __libc_start_call_main (main=main@entry=0x555555684440, argc=argc@entry=3, argv=argv@entry=0x7fffffffda08)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#14 0x00007ffff722a28b in __libc_start_main_impl (main=0x555555684440, argc=3, argv=0x7fffffffda08, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffd9f8) at ../csu/libc-start.c:360
#15 0x0000555555685915 in _start ()
(gdb)

Please let me know if this looks good.

[requinix]

Looks good.

I think you might be running into a bug related to this one, which seems like it was fixed in the v2.3.12 you're using so it's probably not that exactly.

One way or another, the problem does seem to be about connection pooling. Pooling won't gain you anything on the CLI so try disabling it.

[raphael75]

@requinix 

I added Pooling=No to the odbcinst.ini file in the [ODBC] section to look like this:

[MDBTools]
Description=MDBTools Driver
Driver=libmdbodbc.so
Setup=libmdbodbc.so
#FileUsage=1
#UsageCount=1

[ODBC]
Trace=yes
TraceFile=/tmp/odbc.log
Pooling=No

and still got the segmentation fault. I was looking at other options and modified the code to try odbc_connect like this:

$user = '';
$password = '';

$conn = odbc_connect('my_db', $user, $password);
echo 'conn: ';var_dump($conn);

$sql = 'select * from Objects limit 3';

$q = odbc_prepare($conn, $sql);
$success = odbc_execute($q, array());
echo 'success: ';var_dump($success);

$res = odbc_exec($conn, $sql);
echo 'res: ';var_dump($res);

while($row = odbc_fetch_array($res)){
	var_dump($row);
}

exit;

When I run that I get this:

conn: resource(14) of type (odbc link)
success: bool(true)
res: resource(16) of type (odbc result)

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory
PHP Fatal error:  Out of memory (allocated 4194304 bytes) (tried to allocate 2482716230683721760 bytes) in /home/raphael/code/get_mtg_data/import_mtg_data.php on line 17

Fatal error: Out of memory (allocated 4194304 bytes) (tried to allocate 2482716230683721760 bytes) in /home/raphael/code/get_mtg_data/import_mtg_data.php on line 17

Please let me know if you have any other ideas of things I could try. I don't know why it's trying to use all this memory. It seems like it's probably a setting somewhere?

[raphael75]

UPDATE: If I modified the query from "select *..." to "select id, name..." it worked! Do you know what would cause this? Is there any way I can get "select *" to work, or could this be a bug?

[requinix]

That insane number for how much memory it tried to allocate strongly indicates an internal problem. But with both pdo_odbc and the plain odbc extension? Now I'm suspecting MDBTools is the one at fault. Are you using the latest version of that?

8 hours ago, raphael75 said:

UPDATE: If I modified the query from "select *..." to "select id, name..." it worked! Do you know what would cause this? Is there any way I can get "select *" to work, or could this be a bug?

Can you identify exactly which column(s) is causing the problem? What data type is it? Are you able to run SELECT queries on other tables that have a column of the same type?

[raphael75]

Here are the mdbtools versions I have:

mdbtools/noble,now 1.0.0+dfsg-1.2ubuntu1 amd64 [installed]
odbc-mdbtools/noble,now 1.0.0+dfsg-1.2ubuntu1 amd64 [installed]

There are 25 columns in the table, and 4 of them are defined as VARCHAR with a length of 16,777,216. If I try to include any of these columns that are VARCHAR [16,777,216] I get the segmentation fault or the out of memory error I posted above. The rest are all either Integer, SmallInt, Boolean, or VARCHAR that have much smaller lengths (150, 50, 70, etc.). However, some of the smaller VARCHAR fields also cause either the segmentation fault or the out of memory error.

I'm not sure what's going on, but when I try to paste the image of the columns in it just shows a white box. I tried both copying & pasting the image in, and saving it as a local file and uploading, and the same thing happened in both cases.

Edited yesterday at 02:00 AM by raphael75

[requinix]

I'm pretty sure you're encountering https://github.com/mdbtools/mdbtools/issues/312.
Good news is that it was fixed, bad news is that it was fixed in mdbtools 1.0.1 and Ubuntu 24.04 currently only covers through 1.0.0.

There might be a third-party PPA out there that has an updated version, but I don't know where to look for one.
Or you could venture down the path of building it yourself, if you wanted: grab the Ubuntu sources, patch them according to this PR, and build.
Or for a workaround, I think you'll be safe as long as you're not SELECTing anything that requires 64-bits of data length - meaning a VARCHAR(16777215) is okay but a VARCHAR(16777216) is not.