# Fortran libraries to work with parquet files **URL:** \ **Category:** Help\ **Created:** [March 8, 2023, 11:45pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361 "2023-03-08T23:45:10Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [March 8, 2023, 11:45pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/1 "2023-03-08T23:45:10Z")
Does anybody know of any Fortran interface to the Apache arrow ([Apache Arrow — Apache Arrow v11.0.0](https://arrow.apache.org/docs/index.html)) project? I am interested in any Fortran tool that allows reading/writing parquet files in particular, if any exists. ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [March 10, 2023, 10:09pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/2 "2023-03-10T22:09:10Z")
In this [technical report from NASA](https://ntrs.nasa.gov/api/citations/20200001178/downloads/20200001178.pdf) on cloud optimised formats parquet is rated as a good complement to cloud optimised geotiff for handling Earth observation data in the cloud. On page 14 they say that of the 5 languages they consider (Python, R, C, C++, Fortran) Fortran is the only one that doesn’t have a parquet library but the C library can be used with C interoperability. While I’d like to look into it and see if writing the interfaces is within my reach I don’t have the right knowledge to get started. Would the group here have any advice on how to get started with something like this? ---
**Author:** ![freevryheid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/freevryheid/32/357_2.png) [@freevryheid](https://fortran-lang.discourse.group/u/freevryheid)\ **Post date:** [March 13, 2023, 12:06pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/3 "2023-03-13T12:06:42Z")
I gather apache arrow is c++ and the c bindings depend on glib (gnome?). An option is fortran bindings to the [duckdb c api](https://duckdb.org/docs/api/c/overview) that has [parquet](https://duckdb.org/docs/data/parquet/overview) read/write. Extending the existing fortran bindings for the parquet [sqlite extension](https://github.com/cldellow/sqlite-parquet-vtable) is another option I guess. ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [March 13, 2023, 1:45pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/4 "2023-03-13T13:45:08Z")
Thanks for you reply @freevryheid . Indeed arrow is a C++ project and you are right they have C libraries through Glib that provide access to the project from various languages. Additionally arrow does a lot more than just handling parquet so maybe it’s not the best choice for a dependency? With the additional digging I have done in the last few days I have found this documentation for the C (Glib) API: [Apache Arrow GLib (C) | Apache Arrow](https://arrow.apache.org/docs/c_glib/) which also addresses the parquet specifically. My plan based on what I’ve gathered so far was to explore if that can be used directly from Fortran. Up to now I have managed to install arrow with one of the distributed builds and take an example from their repository for a C++ parquet roundtrip: [https://github.com/apache/arrow/blob/main/cpp/examples/parquet/parquet\_arrow/reader\_writer.cc](https://github.com/apache/arrow/blob/main/cpp/examples/parquet/parquet_arrow/reader_writer.cc), link that against the library and run it. That was relatively easy. Next I wanted to try to read/write that same parquet in C with the Glib (C) and then try from Fortran. Maybe along the way I’ll find some blocker. I should also look into the duckdb and sqlite options you mentioned thanks. I am not familiar with either project. I see duckdb is also a C++ project, but I guess will expose a C API that allows binding only the parquet read/write functionality. > Extending the existing fortran bindings for the parquet sqlite extension is another option I guess. I didn’t easily find a reference to these. Could you point me in the right direction? ---
**Author:** ![freevryheid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/freevryheid/32/357_2.png) [@freevryheid](https://fortran-lang.discourse.group/u/freevryheid)\ **Post date:** [March 13, 2023, 1:58pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/5 "2023-03-13T13:58:07Z")
I’ve included links in my original post. Since we already have [sqlite bindings for fortran](https://github.com/interkosmos/fortran-sqlite3) you could read parquet files through the extension. To write I’m guessing you’ll need to export/convert from [csv](https://github.com/cldellow/csv2parquet/). ---
**Author:** ![freevryheid](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/freevryheid/32/357_2.png) [@freevryheid](https://fortran-lang.discourse.group/u/freevryheid)\ **Post date:** [March 15, 2023, 4:28pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/6 "2023-03-15T16:28:40Z")
Started working on duckdb fortran bindings - just the basics to run SQL queries, which can be used to read/write parquet files. I’ll flesh this out as I find time but we could work together on this if you’d like. > **[GitHub - freevryheid/duckdb: fortran bindings to duckdb c api](https://github.com/freevryheid/duckdb)** > > fortran bindings to duckdb c api. Contribute to freevryheid/duckdb development by creating an account on GitHub. ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [March 15, 2023, 6:54pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/7 "2023-03-15T18:54:57Z")
awesome. yes I’d definitively like to contribute. Will take a look at the repository in a bit. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 7, 2023, 12:03pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/8 "2023-04-07T12:03:34Z")
> [@ludnic](#): > > While I’d like to look into it and see if writing the interfaces is within my reach I don’t have the right knowledge to get started. Would the group here have any advice on how to get started with something like this? If ever you are ready for that adventure, you may look at: > [@How to hack my cfwrapper to generate Fortran interfaces for C prototypes](https://fortran-lang.discourse.group/t/how-to-hack-my-cfwrapper-to-generate-fortran-interfaces-for-c-prototypes/5500): > > I have written a How-to for people wanting to try to use (to hack) the gtk-fortran Python cfwrapper with other C libraries: As it was polished for 12 years, you may obtain very good results with “clean” C header files. The problems you may encounter are also detailed. No warranty, it’s a hack! hammer_and_wrench I have made a test with the header files in the directories `/usr/include/arrow-glib` and `/usr/include/parquet-glib` and, with some minimal tweaking (adding some missing GLib types in the wrapper and modifying a regex), obtained 1019 Fortran interfaces like: ```fortran !GParquetArrowFileWriter * gparquet_arrow_file_writer_new_path(GArrowSchema *schema, const gchar *path, GParquetWriterProperties *writer_properties, GError **error); function gparquet_arrow_file_writer_new_path(schema, path, writer_properties,& & error) bind(c) import :: c_ptr, c_char implicit none type(c_ptr) :: gparquet_arrow_file_writer_new_path type(c_ptr), value :: schema character(kind=c_char), dimension(*) :: path type(c_ptr), value :: writer_properties type(c_ptr), value :: error end function ``` If it is those interfaces (arrow-glib and parquet-glib) that you need, I can send you the interfaces for testing. ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [April 7, 2023, 2:22pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/9 "2023-04-07T14:22:38Z")
Sure I’d like to test your auto generated interfaces. I’m have a couple of basic tests that I could run and can add more if it looks promising ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 7, 2023, 2:25pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/10 "2023-04-07T14:25:06Z")
I have sent the two files in a private message. Let me know if you succeed compiling them and use the functions you need. ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [April 9, 2023, 5:10pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/11 "2023-04-09T17:10:23Z")
@vmagnin I’m testing the automatic interfaces here: [GitHub - lucin81/arrow-fortran](https://github.com/lucin81/arrow-fortran) and I’ve shared the development environment I am using with vscocode/docker/modern fortran extension/fpm which should make it very easy for anyone using docker and vscode to fully reproduce this. I think all that is amazing and in my mind it was unthinkable until a few years ago for a Fortran project. So very cool to use fpm and the modern fortran extension for vscode! This is all basic getting started. I’ve been following along the arrow C++ getting started and implementing the same with the fortran bindings created by your cfwrapper script. The idea is to add data into an arrow table and then do I/O operations in the next chapter. If I manage to get it to work properly will look into organising the interfaces to make it more user friendly. I’ve managed to work through the first functions and I’m now seeing some issue that maybe someone here knows about: This function that creates a schema from an array of fields: `garrow_schema_new` defined in the [API reference](https://arrow.apache.org/docs/c_glib/arrow-glib/GArrowSchema.html#garrow-schema-new) got translated by cfwrapper with the following: ```fortran !GArrowSchema *garrow_schema_new (GList *fields); function garrow_schema_new(fields) bind(c) import :: c_ptr implicit none type(c_ptr) :: garrow_schema_new type(c_ptr), value :: fields end function ``` Here the `fields` variable is a `Glist` array in C and the cfwrapper makes it into a `type(c_ptr), value :: fields`. I’m trying to us it as: ```fortran type(c_ptr) :: field_days, field_months, field_years type(c_ptr) :: fields_array(3) type(c_ptr) :: schema field_days = garrow_field_new('days'//c_null_char, garrow_int8_data_type_new()) field_months = garrow_field_new('months'//c_null_char, garrow_int8_data_type_new()) field_years = garrow_field_new('years'//c_null_char, garrow_int16_data_type_new()) fields_array = [field_days, field_months, field_years] schema = garrow_schema_new(fields_array) ``` But that gives a memory error: > **invalid uninstantiatable type 'void' in cast to 'GArrowField'** > > ```auto > (process:77109): GLib-GObject-WARNING **: 16:52:26.625: invalid uninstantiatable type 'void' in cast to 'GArrowField' > > (process:77109): GLib-GObject-WARNING **: 16:52:26.625: invalid uninstantiatable type 'void' in cast to 'GArrowField' > > Program received signal SIGSEGV: Segmentation fault - invalid memory reference. > > Backtrace for this error: > #0 0xffffa4f1d08b in ??? > #1 0xffffa4f1c047 in ??? > #2 0xffffa520c78f in ??? > #3 0xffffa5170ac0 in ??? > #4 0xffffa5110f27 in ??? > #5 0xffffa513131b in ??? > #6 0xaaaae3180e13 in MAIN__ > at app/main.f90:75 > #7 0xaaaae3180e53 in main > at app/main.f90:5 > Segmentation fault > Execution failed for object " parquet-glib " > *cmd_run*:stopping due to failed executions > STOP 1 > > ``` Any idea how to deal with glibc GList object from Fortran? ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 9, 2023, 7:06pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/12 "2023-04-09T19:06:09Z")
Writing the Fortran interfaces are half the work (or less than half the work)… When you use basic C types, it’s easy. But with derived types and elaborated structures, things become harder. On the C side I have that PDF on GTK development which describes GLists: [http://devernay.free.fr/cours/IHM/GTK/GGAD.pdf](http://devernay.free.fr/cours/IHM/GTK/GGAD.pdf) It’s not fresh (1999) but I guess that that part of the GLib must be stable. I have also [GLib/GLib Data Types — Wikiversité](https://fr.wikiversity.org/wiki/GLib/GLib_Data_Types#GList) but sorry it’s in French. Personally, I have never used GLists but J. Tappin (the author of the High Level library) used some `g_list` or `g_slist` functions in those files of gtk-fortran: `src/gdk-pixbuf-hl.f90` `src/gtk-hl-button.f90` `src/gtk-hl-chooser.f90` `src/gtk-hl-tree.f90` (maybe the more interesting) Maybe we could find some interesting code there… I will try to have a look at your GitHub code. Remark: do not confuse GLib and glibc. GLib is a library used by GNOME applications and GTK. > **[GLib](https://en.wikipedia.org/wiki/GLib)** > > GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib's code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since. > GLib provides advanced data structures, such as memory chunks, doubly and singly linked lists, hash tables, dynamic strings and string utilities, such as a lexical scanner, string chunks (groups of strings), dynamic arrays, balanced binary trees, N-ary tre... > **[glibc](https://en.wikipedia.org/wiki/Glibc)** > > The GNU C Library, commonly known as glibc, is the GNU Project's implementation of the C standard library. Despite its name, it now also directly supports C++ (and, indirectly, other programming languages). It was started in the 1980s by the Free Software Foundation (FSF) for the GNU operating system. > Released under the GNU Lesser General Public License, glibc is free software. The GNU C Library project provides the core libraries for the GNU system, as well as many systems that use Linux as t... ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 9, 2023, 7:16pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/13 "2023-04-09T19:16:53Z")
And if you need GList functions, you will need to copy in your `src` directory the module `src/glib-auto.f90` from gtk-fortran. You may also be interested by the GLib documentation: > **[GLib.List](https://docs.gtk.org/glib/struct.List.html)** > > Reference for GLib.List ```plaintext struct GList { gpointer data; GList* next; GList* prev; } ``` So I guess a GList would be in Fortran something like: ```plaintext type, bind(c) :: GList type(c_ptr) :: data type(c_ptr) :: next type(c_ptr) :: prev end type GList ``` ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [April 9, 2023, 8:04pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/14 "2023-04-09T20:04:18Z")
> [@vmagnin](#): > > Remark: do not confuse GLib and glibc. GLib is a library used by GNOME applications and GTK. > > [GLib - Wikipedia](https://en.wikipedia.org/wiki/GLib) Thanks for mentioning. That was confusing to me. > [@vmagnin](#): > > And if you need GList functions, you will need to copy in your `src` directory the module `src/glib-auto.f90` from gtk-fortran. Indeed I was wondering if that is what’s needed here. Why does the cfwrapper script converts the `GList` argument to `type(c_ptr)`? Is it possible to just ignore any details of the glib data types and let C deal with it or do we need to have all the glib types available in fortran and therefore I guess modify the auto-generated bindings to use the glib types? From a quick look at how some of the functions operating on `GList` are used in some of the gtk-fortran sources you mentioned they seem to operate on `type(c_ptr)` objects. I don’t see a fortran derived type that represents a `GList`. But maybe I need to take a closer look, thanks for pointing at those. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 9, 2023, 8:33pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/15 "2023-04-09T20:33:44Z")
Yes, you are right, most of the time you don’t have to implement the GLib type. You call a GLib function that creates an “object” with that type and returns a C pointer to that object, and you pass that pointer to another function, etc. Looking at the GList API in the doc, I see no `g_list_new()` function as I expected. But it seems you could use `g_list_alloc()` to create an empty GList (and obtain a pointer to that list). And then `g_list_append()` to append a data to that list, and so on. > **[GLib.List.alloc](https://docs.gtk.org/glib/type_func.List.alloc.html)** > > Reference for GLib.List.alloc > **[GLib.List.append](https://docs.gtk.org/glib/type_func.List.append.html)** > > Reference for GLib.List.append Then you could pass the pointer to `garrow_schema_new()` ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 10, 2023, 8:34am UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/16 "2023-04-10T08:34:53Z")
> [@vmagnin](#): > > And if you need GList functions, you will need to copy in your `src` directory the module `src/glib-auto.f90` from gtk-fortran. To be more precise, I think that if you want to respect the GPL license and don’t mean to distribute your work under the same license, what you can do is just picking in `glib-auto.f90` the interfaces you need for your project. We can consider that a Fortran interface is a generic code (no creativity) and can therefore not be protected by a license: there is nearly only one way to write an interface to a C function (no choice on the data types, and you will generally use the same names). But a file containing 4000 interfaces can be licensed as it implies either creativity (an automatic wrapper) or a considerable amount of work. That same idea is expressed in the databases protection laws: “You or the maker of the database can prevent the extraction and/or reuse of the whole or a substantial part of the database’s content”. The important word being _substantial._ ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [April 10, 2023, 1:50pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/17 "2023-04-10T13:50:29Z")
> [@vmagnin](#): > > To be more precise, I think that if you want to respect the GPL license and don’t mean to distribute your work under the same license, what you can do is just picking in `glib-auto.f90` the interfaces you need for your project. I’m actually very happy to share this with the appropriate license. I’ve add the GPL license file, hope that works. ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 10, 2023, 1:54pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/18 "2023-04-10T13:54:04Z")
As you want! Have you made some progress with the GLists? ---
**Author:** ![ludnic](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@ludnic](https://fortran-lang.discourse.group/u/ludnic)\ **Post date:** [April 10, 2023, 2:05pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/19 "2023-04-10T14:05:18Z")
I did try it, but unfortunately it does not solve the issue as there is still a segmentation fault when calling the `arrow_schema_new` function. ```fortran type(c_ptr) :: fields_list type(c_ptr) :: schema fields_list = g_list_alloc() fields_list = g_list_append(fields_list, field_days) fields_list = g_list_append(fields_list, field_months) fields_list = g_list_append(fields_list, field_years) schema = garrow_schema_new(fields_list) ``` > **output** > > ```plaintext > root@9ebf5bb08910:/workspaces/parquet-glib# fpm run > main.f90 done. > parquet-glib done. > [100%] Project compiled successfully. > days: int8 > months: int8 > years: int16 > > Program received signal SIGSEGV: Segmentation fault - invalid memory reference. > > Backtrace for this error: > #0 0xffff83a3d08b in ??? > #1 0xffff83a3c047 in ??? > #2 0xffff83e7378f in ??? > #3 0xffff83d80ee0 in ??? > #4 0xffff83da131b in ??? > #5 0xaaaad75e13cf in MAIN__ > at app/main.f90:94 > #6 0xaaaad75e1413 in main > at app/main.f90:5 > Segmentation fault > Execution failed for object " parquet-glib " > *cmd_run*:stopping due to failed executions > STOP 1 > > ``` _Edit: added valgrind output_ > **valgrind output** > > ```plaintext > root@9ebf5bb08910:/workspaces/parquet-glib# fpm run --runner 'valgrind --track-origins=yes' > parquet-glib done. > [100%] Project compiled successfully. > ==12293== Memcheck, a memory error detector > ==12293== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==12293== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info > ==12293== Command: build/gfortran_2A42023B310FA28D/app/parquet-glib > ==12293== > ==12293== Conditional jump or move depends on uninitialised value(s) > ==12293== at 0x50D8178: arrow::ArrayData::Make(std::shared_ptr, long, std::vector, std::allocator > >, long, long) (in /usr/lib/aarch64-linux-gnu/libarrow.so.1100.0.0) > ==12293== by 0x51AB4D3: ??? (in /usr/lib/aarch64-linux-gnu/libarrow.so.1100.0.0) > ==12293== by 0x50C0F27: arrow::ArrayBuilder::Finish(std::shared_ptr*) (in /usr/lib/aarch64-linux-gnu/libarrow.so.1100.0.0) > ==12293== by 0x48DC0D3: garrow_array_builder_finish (in /usr/lib/aarch64-linux-gnu/libarrow-glib.so.1100.0.0) > ==12293== by 0x1090AB: MAIN__ (main.f90:39) > ==12293== by 0x109413: main (main.f90:5) > ==12293== Uninitialised value was created by a stack allocation > ==12293== at 0x109014: MAIN__ (main.f90:1) > ==12293== > days: int8 > months: int8 > years: int16 > ==12293== Invalid read of size 8 > ==12293== at 0x4910EE0: garrow_field_get_raw(_GArrowField*) (in /usr/lib/aarch64-linux-gnu/libarrow-glib.so.1100.0.0) > ==12293== by 0x493131B: garrow_schema_new (in /usr/lib/aarch64-linux-gnu/libarrow-glib.so.1100.0.0) > ==12293== by 0x1093CF: MAIN__ (main.f90:94) > ==12293== by 0x109413: main (main.f90:5) > ==12293== Address 0xffffffffffffffe0 is not stack'd, malloc'd or (recently) free'd > ==12293== > > Program received signal SIGSEGV: Segmentation fault - invalid memory reference. > > Backtrace for this error: > #0 0x4b3d08b in ??? > #1 0x4b3c047 in ??? > #2 0x580b917f in ??? > #3 0x4910ee0 in ??? > #4 0x493131b in ??? > #5 0x1093cf in MAIN__ > at app/main.f90:94 > #6 0x109413 in main > at app/main.f90:5 > ==12293== > ==12293== Process terminating with default action of signal 11 (SIGSEGV) > ==12293== at 0x4D2F200: __pthread_kill_implementation (pthread_kill.c:44) > ==12293== by 0x4CEA67B: raise (raise.c:26) > ==12293== by 0x580B917F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux) > ==12293== > ==12293== HEAP SUMMARY: > ==12293== in use at exit: 335,520 bytes in 2,330 blocks > ==12293== total heap usage: 4,003 allocs, 1,673 frees, 563,066 bytes allocated > ==12293== > ==12293== LEAK SUMMARY: > ==12293== definitely lost: 0 bytes in 0 blocks > ==12293== indirectly lost: 0 bytes in 0 blocks > ==12293== possibly lost: 432 bytes in 1 blocks > ==12293== still reachable: 330,816 bytes in 2,286 blocks > ==12293== suppressed: 0 bytes in 0 blocks > ==12293== Rerun with --leak-check=full to see details of leaked memory > ==12293== > ==12293== For lists of detected and suppressed errors, rerun with: -s > ==12293== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) > Segmentation fault > Execution failed for object " parquet-glib " > *cmd_run*:stopping due to failed executions > STOP 1 > > ``` ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [April 10, 2023, 2:55pm UTC](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361/20 "2023-04-10T14:55:12Z")
Same problem here in a Fedora Rawhide virtual machine. But replacing this line: ```fortran fields_list = g_list_alloc() ``` by: ```fortran fields_list = c_null_ptr ``` It runs. I have just mimicked C code I found in a GLib [example](https://github.com/ToshioCP/Gtk4-tutorial/blob/3cdb5ac6e1475cdae935cdee5708a4c2e113435c/src/list5/list5.c#L40). So it does not crash. Does it really do what you want? I don’t know, but there is hope. [Next page](https://fortran-lang.discourse.group/t/fortran-libraries-to-work-with-parquet-files/5361.md?page=2)