search

termux / termux-packages

A package build system for Termux.
https://termux.dev
Other
12.94k stars 2.98k forks source link

[Bug]: gnucobol fails to write indexed files #20818

Open alexbodn opened 1 month ago

alexbodn commented 1 month ago

Problem description

a program meant to write to an indexed file fails to do so under termux. it does work as expected under arm64 linux, while the index backend happens to be bdb. i'll attach the program, naturally.

What steps will reproduce the bug?

build the program i include and run the executable under termux and elsewhere, say linux.

What is the expected behavior?

writing data to the indexed file.

System information

Termux Variables:
TERMUX_API_VERSION=0.50.1                                  TERMUX_APK_RELEASE=F_DROID
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=11929
TERMUX_IS_DEBUGGABLE_BUILD=0                               TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
TERMUX__USER_ID=0
Packages CPU architecture:                                 aarch64
Subscribed repositories:
# sources.list
deb https://ro.mirror.flokinet.net/termux/termux-main stable main                                                     Updatable packages:
All packages up to date
termux-tools version:
1.42.4                                                     Android version:
13
Kernel build information:
Linux localhost 5.4.233-qgki-gc8d58398c11d #1 SMP PREEMPT Thu May 23 15:08:27 UTC 2024 aarch64 Android
Device manufacturer:
HMD Global
Device model:
Nokia XR20
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
Installed termux plugins:
com.termux.api versionCode:51

GnuCOBOL information
COB_MODULE_EXT           : so
dynamic loading          : system
64bit-mode               : yes
BINARY-C-LONG            : 8 bytes
endianness               : little-endian
native EBCDIC            : no
variable file format     : 0
sequential file handler  : built-in
indexed file handler     : VBISAM
mathematical library     : GMP, version 6.3.0
XML library              : libxml2, version 2.12.7
JSON library             : json-c, version 0.17.0
extended screen I/O      : ncursesw, version 6.4.20231001 (CHTYPE=32, WIDE=1)
mouse support            : unknown
alexbodn commented 1 month ago

*>this is my offending program

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

ENVIRONMENT DIVISION.
   INPUT-OUTPUT SECTION.
      FILE-CONTROL.
      SELECT STUDENT-DB ASSIGN TO 'students'
         ORGANIZATION IS INDEXED
         ACCESS MODE IS RANDOM
         *>ACCESS MODE IS SEQUENTIAL
         RECORD KEY IS DB-STUDENT-ID
         FILE STATUS IS FS.

DATA DIVISION.
   FILE SECTION.
   FD STUDENT-DB.
   01 DB-STUDENT.
      05 DB-STUDENT-ID PIC 9(5).
      05 DB-NAME PIC A(25).
      05 DB-CLASS PIC X(3).

   WORKING-STORAGE SECTION.
   01 FS PIC X(2).

PROCEDURE DIVISION.
   OPEN i-o STUDENT-DB.
   DISPLAY "FS open : "FS END-DISPLAY.
   move 1000 TO DB-STUDENT-ID.
   move 'Tim' TO DB-NAME.
   move '10' TO DB-CLASS.
   DISPLAY 'DB-STUDENT-ID : 'DB-STUDENT-ID END-DISPLAY.
   DISPLAY 'DB-NAME : 'DB-NAME END-DISPLAY.
   DISPLAY 'DB-CLASS : 'DB-CLASS END-DISPLAY.
   DISPLAY 'DB-STUDENT : 'DB-STUDENT END-DISPLAY.
   WRITE DB-STUDENT END-WRITE.
   DISPLAY "FS write : "FS END-DISPLAY.
   CLOSE STUDENT-DB.
   DISPLAY "FS close : "FS END-DISPLAY.
STOP RUN.
Biswa96 commented 1 month ago

Could you provide all the steps to reproduce the issue?

GitMensch commented 1 month ago

According to the related StackOverflow question that should be cobc -d -free -Wall -Wextra -Wadditional -xj index-create.cbl.

Expected "working" output would then be:

FS open : 05
DB-STUDENT-ID : 01000
DB-NAME : Tim
DB-CLASS : 10
DB-STUDENT : 01000Tim                      10
FS write : 00
FS close : 00

I think that's rooted in the gnucobol package being built with VBISAM as dependency instead of BDB. As the later is the default envrionment for GnuCOBOL since two decades and the backend that's commonly used in distributions (including in MSYS2 ;-) it is likely useful to switch that.

[Warning note: this would make all püreviously created indexed files on Termux not readable anymore after the package update :-/ ]

@alexbodn: you may want to try doing an explicit OPEN EXTEND STUDENT-DB. IF FS (1:1) NOT = "0" OPEN OUTPUT STUDENT-DB. which may or may not work.

Biswa96 commented 1 month ago

I get the following output in termux and it matches with your expected result.

$ cobc -d -free -Wall -Wextra -Wadditional -xj index-create.cbl
FS open : 35
DB-STUDENT-ID : 01000
DB-NAME : Tim
DB-CLASS : 10
DB-STUDENT : 01000Tim                      10
FS write : 48
FS close : 42
GitMensch commented 1 month ago

Expected would be status "00" or "05" then only "00" and I think that should be the case if the BDB backend is used.

alexbodn commented 1 month ago

@alexbodn: you may want to try doing an explicit OPEN EXTEND STUDENT-DB. IF FS (1:1) NOT = "0" OPEN OUTPUT STUDENT-DB. which may or may not work.

@GitMensch i retried your suggestion with the same unfortunate result.

GitMensch commented 1 month ago

Thanks for the test, that means that either the GnuCOBOL version in the distro or (more likely) the VBISAM version doesn't work well with Termux.

While this is hopefully not an issue with the upcoming update to that library (late this year), it seems that the most reasonable option is to change the gnucobol package in termux to use libdb instead of livbisam then.

@xtkoba: Did you chose libvbisam on purpose over libdb? As the recipe in termux does not define a test/check target, did someone executed make checkall to verify if the libvbisam version works better (or at all with Indedex-sequential files) than the libdb one?

Biswa96 commented 1 month ago

xtkoba is not active in GitHub for many months. You can try to rebuild the package with required changes and test it.

GitMensch commented 1 month ago

xtkoba is not active in GitHub for many months. You can try to rebuild the package with required changes and test it.

That would likely go to @alexbodn for now. Alex, could you try to build the package per wiki? Maybe you can also include a "make check" after the build and save the resulting tests/testsuite.log.

The next step would be to then adjust the package locally to swap libvbisam to libdb and drop --with-vbisam by --with-db and see what the different result in testsuite.log is.

If we see that's better (and your program pass with that version) then we could update the package definition.

alexbodn commented 1 month ago

my first attempt to install the docker image ruined my vm computer, and i'm still trying to regain control on it. i'll check another way to do it.

Biswa96 commented 1 month ago

i'll check another way to do it.

You could fork this repository, enable CI, add your required changes and let CI do the work for you.

alexbodn commented 1 month ago

i'll check another way to do it.

You could fork this repository, enable CI, add your required changes and let CI do the work for you.

I hoped for such a solution, thank you. So i'll have to make the changes to the gnucobol package recipe and save the changes? But where will the new deb be?

Biswa96 commented 1 month ago

But where will the new deb be?

In CI artifacts. You have to enable the GitHub Actions and run the "packages" workflow with proper inputs - branch name and gnucobol in package name.

alexbodn commented 1 month ago

thank you @Biswa96 , indeed the build was successful after my first attempt to patch. the program is attempting to open a bdb file in the same location, but it doesn't and gives an error related with missing write permissions. good @GitMensch i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.

alexbodn commented 1 month ago

small progress:

a little program i wrote in c and built on termux with packaged libdb, does properly access, and eventually create, a bdb file in the current directory.

GitMensch commented 1 month ago

i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.

There's something wrong - status 91 is "not available" (= built without INDEXED support, which should not happen when if you don't use --without-db).

GitMensch commented 1 month ago

Checking the CI runs I see that BDB is used, so there shouldn't be a status 91.

For some reasons it builds GnuCOBOL 3.1.2 - I highly suggest to move to GnuCOBOL 3.2 instead (full backward-compatibility down to GC 2.2) which likely should allow to drop the configure patch as well,

alexbodn commented 1 month ago

i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.

There's something wrong - status 91 is "not available" (= built without INDEXED support, which should not happen when if you don't use --without-db).

the original package was 3.1.2, configured --with -vbisam --without-db. status was 30/35, with .dat and .idx created. inverting these switches, with 3.1.2 yet, got status 91.

alexbodn commented 1 month ago

Checking the CI runs I see that BDB is used, so there shouldn't be a status 91.

For some reasons it builds GnuCOBOL 3.1.2 - I highly suggest to move to GnuCOBOL 3.2 instead (full backward-compatibility down to GC 2.2) which likely should allow to drop the configure patch as well,

working on 3.2, but didn't seem to recognize libdb. but the result is disabling indexed handling altogether.

alexbodn commented 1 month ago

i fixed this issue and intend to pull request. thank you for your collaboration and support.