Pro*C program run properly in AIX but not in RHEL - compilation

I have some trouble running a binary done with proC code. I can compile it (without warnings) in my new server RHEL (7.8) but it loops until it failed. I made a simple proC script to test the compilation (see below). This script runs easily in my previous server AIX (6.1.0.0). The DB is Oracle 11c.
Oracle client in AIX : .../oracle/10.2
Oracle client in RHEL : .../oracle/12102/cli64
Here my simple code I want to compile and execute :
#include "demo.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sqlca.h>
#include <oraca.h>
int code_erreur;
char libelle_erreur[200];
EXEC ORACLE OPTION (ORACA=YES);
EXEC SQL BEGIN DECLARE SECTION;
VARCHAR username[30];
VARCHAR password[30];
VARCHAR host[30];
VARCHAR dynstmt[80];
VARCHAR mData[81];
EXEC SQL END DECLARE SECTION;
int connect()
{
printf("\nConnection to %s#%s\n",username.arr,host.arr);
EXEC SQL CONNECT :username IDENTIFIED BY :password USING :host;
printf("Connection established\n");
return 0;
}
void sqlerr()
{
code_erreur = sqlca.sqlcode;
strcpy(libelle_erreur,sqlca.sqlerrm.sqlerrmc);
printf("SQL ERROR : %d,%s ;\n", code_erreur,libelle_erreur);
printf("sqlca.sqlerrd : %d\n",sqlca.sqlerrd[2]);
}
int loadData()
{
int lIter;
strcpy(dynstmt.arr, "SELECT BANNER FROM V$VERSION\n");
dynstmt.len = strlen(dynstmt.arr);
printf("%s", (char *)dynstmt.arr);
EXEC SQL PREPARE S FROM :dynstmt;
EXEC SQL DECLARE lCursorData CURSOR FOR S;
EXEC SQL OPEN lCursorData;
for (lIter=0;lIter<10;lIter++)
{
EXEC SQL WHENEVER NOT FOUND DO break;
EXEC SQL FETCH lCursorData INTO :mData;
printf("%s\n", mData.arr);
}
EXECL SQL CLOSE lCursorData;
return 0;
}
void main()
{
int lRetour=0;
printf("Start demo\n");
strcpy((char *)username.arr,"USER");
username.len=(unsigned short)strlen((char *)username.arr);
strcpy((char *)password.arr,"PASS");
password.len=(unsigned short)strlen((char *)password.arr);
strcpy((char *)host.arr,"HOST");
host.len=(unsigned short)strlen((char *)host.arr);
EXEC SQL WHENEVER SQLERROR do sqlerr();
lRetour = connect();
lRetour = loadData();
EXEC SQL COMMIT WORK RELEASE;
printf("End demo\n");
exit(0);
}
When I compile it and execute it on my AIX server, here what I got :
Start demo
Connection to USER#HOST
Connection established
SELECT BANNER FROM V$VERSION
[...]
End demo
But when I compile it on RHEL and execute it, the binary loops until a memory fault :
[...]
Connection to USER#HOST
Connection to USER#HOST
Connection to USER#HOST
Memory fault
Of course I want the same AIX result in RHEL.

Your connect function should be defined as static, otherwize it replaces connect(2) library function from libc.
## -20,7 +20,7 ##
EXEC SQL END DECLARE SECTION;
-int connect()
+static int connect()
{
printf("\nConnection to %s#%s\n",username.arr,host.arr);
## -57,7 +57,7 ##

Related

Runtime error : Segmentation fault with libtommath and libtomcrypt

I am trying to run sample rsa/dsa code using libtomcrypt.
I have installed LibTomMath first as make install, as a result following files are created.
/usr/lib/libtommath.a
/usr/include/tommath.h
After that I installed libtomcrypt with LibTomMath as external library
CFLAGS="-DLTM_DESC -DUSE_LTM -I/usr/include" EXTRALIBS="/usr/lib/libtommath.a " make install
As a result following file is created
/usr/lib/libtomcrypt.a
I am not getting any error while running following command
CFLAGS="-DLTM_DESC -DUSE_LTM -I/usr/include" EXTRALIBS="/usr/lib/libtommath.a " make test
I have gone through this document libtomcrypt_installation and libtomcrypt_resolved to successfully compile using
gcc -DLTM_DESC rsa_make_key_example.c -o rsa -ltomcrypt
or
gcc rsa_make_key_example.c -o rsa -ltomcrypt
no compile error. However when I try to run, I got following error.
./rsa
LTC_ARGCHK 'ltc_mp.name != NULL' failure on line 34 of file src/pk/rsa/rsa_make_key.c
Aborted
Here is my sample rsa code
#include <tomcrypt.h>
#include <stdio.h>
int main(void) {
# ifdef USE_LTM
ltc_mp = ltm_desc;
# elif defined (USE_TFM)
ltc_mp = tfm_desc;
# endif
rsa_key key;
int err;
register_prng(&sprng_desc);
if ((err = rsa_make_key(NULL, find_prng("sprng"), 1024/8, 65537,&key)) != CRYPT_OK) {
printf("make_key error: %s\n", error_to_string(err));
return -1;
}
/* use the key ... */
return 0;
}
Here is my sample dsa code
#include <tomcrypt.h>
#include <stdio.h>
int main(void) {
# ifdef USE_LTM
ltc_mp = ltm_desc;
# elif defined (USE_TFM)
ltc_mp = tfm_desc;
# endif
int err;
register_prng(&sprng_desc);
dsa_key key;
if ((err = dsa_make_key(NULL, find_prng("sprng"), 20, 128,&key)) != CRYPT_OK) {
printf("make_key error: %s\n", error_to_string(err));
return -1;
}
/* use the key ... */
return 0;
}
Here is how I have compiled it successfully,
gcc dsa_make_key_example.c -o dsa -ltomcrypt
When I try to run the code , I am getting following error .
./dsa
segmentation fault
EDIT 1:
I investigated further and found the reason for segmentation fault
#ifdef LTC_MPI
#include <stdarg.h>
int ltc_init_multi(void **a, ...)
{
...
...
if (mp_init(cur) != CRYPT_OK) ---> This line causes segmentation fault
Where am I making mistakes ? How to resolve this problem to run these programs successfully?
I am using linux , gcc. Any help/link will be highly appreciated. Thanks in advance.
It's been a year or so since this was asked, but I have some component of an answer, and a workaround.
The reason mp_init fails is that the "math_descriptor" is uninitialized. mp_init is a defined as
#define mp_init(a) ltc_mp.init(a)
where ltc_mp is a global struct (of type ltc_math_descriptor) that holds pointers to the math routines.
There are several implementations of the math routines available, and a user can choose which they want. For whatever reason, there does not seem to be a default math implementation chosen for certain builds of libtomcrypt. Thus, the init member of ltc_mp is null, and we get the SIGSEGV.
Here is a manual workaround:
You can make your desired ltc_math_descriptor struct available to your main() routine by #defineing one of
LTM_DESC -- built-in math lib
TFM_DESC -- an external fast math package
GMP_DESC -- presumably a GNU MultiPrecision implementation?
Before #include <tomcrypt.h> (or by using -D on the command-line).
Whichever you choose, a corresponding object will be declared:
extern const ltc_math_descriptor ltm_desc;
extern const ltc_math_descriptor tfm_desc;
extern const ltc_math_descriptor gmp_desc;
To use it, manually copy it to the global math descriptor:
E.g., in my case, for the local math imlpementation,
ltc_mp = ltm_desc;
Now libtomcrypt works.

Program hangs after execvp(fork-and-exec simple console application)

I tried to write simple fork-and-exec application with the following code
#include <stdlib.h>
#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>
int
spawn(char *program, char *arg_list[])
{
pid_t child_pid;
child_pid = fork();
if (child_pid != 0)
return child_pid;
else {
execvp(program, arg_list);
fprintf(stderr, "an error occured\n");
exit(EXIT_FAILURE);
}
}
int
main()
{
int child_stat;
char *arg_list[] = {
"ls",
"-l",
"/",
NULL
};
spawn("ls", arg_list);
printf("return to parent\n");
return 0;
}
Every goes fine, but child after becoming ls does not terminate.
Shell looks like
./main
return to parent
-- ls output here --
But command prompt does not appear, so I assume that one process hangs and the reason is not obvious for me. Can you, please, point to my mistake.
Thanks in advance.
I believe that it works correctly. However, the order of execution of the child and parent are not what you expect, so you see output you don't understand. On my Arch linux box (kernel 4.xx), it works fine, but the parent process returns first, leaving ls to overwrite and otherwise garble the command prompt. Do a wait() on the child process to get execution to happen in a specific order. Add a couple of lines of code after the spawn() call:
spawn("ls", arg_list);
printf("return to parent\n");
wait(&child_stat);
printf("Waited on child\n");
return 0;
After the fork() call, the parent process will call wait(), which won't return until a child process (if there is at least one) exits. Since there's only one child process, the output of ls occurs before the command prompt gets written out, and thus you will see what you believe you should see.

Specific pipe command in Ubuntu's shell handling in C

I'm trying to simulate a pipe behavior on Ubuntu's Terminal, for example the command:
"echo hello | wc".
Please assume I got the tokens from stdin, handled everything correctly and now These are the commands I "received" from the user who typed them in the shell for me to handle.
I'm trying to create two processes. Using a pipe, in the first process, I point the file descriptor of the writing edge of the pipe to stdout. The second process should read into stdin with the reading edge of the pipe what execvp(..) returned.?
Here is the code I wrote:
#include <stdio.h>
#include <stdlib.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
int main()
{
char* fcmd[] = {"echo", "hello", NULL};
char* scmd[] = {"wc", NULL};
pid_t pid;
int pipe_des[2];
int i;
pipe(pipe_des);
for(i = 0; i < 2; i++)
{
pid = fork();
if (pid ==0)
{
switch (i)
{
case 0: // FIRST CHILD
{
dup2(pipe_des[1], STDOUT_FILENO);
close(pipe_des[0]);
execvp(fcmd[0], fcmd);
exit(0);
}
case 1: //SECOND CHILD
{
dup2(pipe_des[0], STDIN_FILENO);
close(pipe_des[1]);
execvp(scmd[0], scmd);
exit(0);
}
}
}
else if (pid < 0)
exit(EXIT_FAILURE);
return EXIT_SUCCESS;
}
I get: " amirla#ubuntu:~/Desktop/os/class/ex4$ 1 1 6 "
Like it should, but why he's printing the bash cwd first? The pipe seems to work because I get what I should, according to the length of the word I'm sending with the echo command(in the main()). After that the cursor just waits on the line below for another command without showing me the bash pwd. (maybe stdin is waiting?)
I've looked in many posts on here as well as on other websites and I still can't seem to find a solution to my problem. Any help would be appreciated. Thanks in advance.
Note: Please Ignore checking for errors, I've delete them to make the code shorter so assume they exist.
Why do I get a prompt before the output?
Your main process doesn't wait for the children to finish. What you see is:
Main starts
Main creates children
Main exits
BASH prints prompt
Children start their work
To prevent this, you need to wait for the children. See How to wait until all child processes called by fork() complete?
In your case, it's enough to add
waitpid(-1, NULL, 0);
after the loop.

How to make lldb ignore EXC_BAD_ACCESS exception?

I am writing a program on Mac OSX depending on the sigaction/sa_handler mechanism. Run a code snippet from user and get ready to catch signals/exceptions at any time. The program works fine, but the problem is I can't debug it with lldb. lldb seems not being able to ignore any exceptions even I set
proc hand -p true -s false SIGSEGV
proc hand -p true -s false SIGBUS
The control flow stops at the instruction that triggers the exception and does not jump to the sa_handler I installed earlier even I tried command c. The output was:
Process 764 stopped
* thread #2: tid = 0xf140, 0x00000001000b8000, stop reason = EXC_BAD_ACCESS (code=2, address=0x1000b8000)
How do I make lldb ignore the exception/signal and let the sa_handler of the program do its work?
EDIT: sample code
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <pthread.h>
#include <unistd.h>
static void handler(int signo, siginfo_t *sigaction, void *context)
{
printf("in handler.\n");
signal(signo, SIG_DFL);
}
static void gen_exception()
{
printf("gen_exception in.\n");
*(int *)0 = 0;
printf("gen_exception out.\n");
}
void *gen_exception_thread(void *parg)
{
gen_exception();
return 0;
}
int main()
{
struct sigaction sa;
sa.sa_sigaction = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if(sigaction(/*SIGBUS*/SIGSEGV, &sa, NULL) == -1) {
printf("sigaction fails.\n");
return 0;
}
pthread_t id;
pthread_create(&id, NULL, gen_exception_thread, NULL);
pthread_join(id, NULL);
return 0;
}
I needed this in a recent project, so I just built my own LLDB. I patched a line in tools/debugserver/source/MacOSX/MachTask.mm from
err = ::task_set_exception_ports (task, m_exc_port_info.mask, m_exception_port, EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES, THREAD_STATE_NONE);
to
err = ::task_set_exception_ports (task, m_exc_port_info.mask & ~EXC_MASK_BAD_ACCESS, m_exception_port, EXCEPTION_DEFAULT | MACH_EXCEPTION_CODES, THREAD_STATE_NONE);
which causes the debugserver to be unable to catch EXC_BAD_ACCESS exceptions. Now, my custom LLDB works just fine: it still catches SIGSEGV and SIGBUS but no longer enters a silly infinite loop when faced with EXC_BAD_ACCESS. Setting process handle options on the previously-fatal signals works fine too, and I can now debug SEGV handlers with impunity.
Apple really ought to make this an option in LLDB...seems like a really easy fix for them.
This is a long-standing bug in the debugger interface in Mac OS X (gdb had the same problem...) If you have a developer account, please file a bug with http://bugreport.apple.com. So few people actually use SIGSEGV handlers that the problem never gets any attention from the kernel folks, so more bugs is good...
We can do it easily. Just add this code.
#include <mach/task.h>
#include <mach/mach_init.h>
#include <mach/mach_port.h>
int ret = task_set_exception_ports(
mach_task_self(),
EXC_MASK_BAD_ACCESS,
MACH_PORT_NULL,//m_exception_port,
EXCEPTION_DEFAULT,
0);
Don't forget to do this
proc hand -p true -s false SIGSEGV
proc hand -p true -s false SIGBUS
Full code:
#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <pthread.h>
#include <unistd.h>
#include <mach/task.h>
#include <mach/mach_init.h>
#include <mach/mach_port.h>
static void handler(int signo, siginfo_t *sigaction, void *context)
{
printf("in handler.\n");
signal(signo, SIG_DFL);
}
static void gen_exception()
{
printf("gen_exception in.\n");
*(int *)0 = 0;
printf("gen_exception out.\n");
}
void *gen_exception_thread(void *parg)
{
gen_exception();
return 0;
}
int main()
{
task_set_exception_ports(
mach_task_self(),
EXC_MASK_BAD_ACCESS,
MACH_PORT_NULL,//m_exception_port,
EXCEPTION_DEFAULT,
0);
struct sigaction sa;
sa.sa_sigaction = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if(sigaction(/*SIGBUS*/SIGSEGV, &sa, NULL) == -1) {
printf("sigaction fails.\n");
return 0;
}
pthread_t id;
pthread_create(&id, NULL, gen_exception_thread, NULL);
pthread_join(id, NULL);
return 0;
}
Refer to (Chinese article): https://zhuanlan.zhihu.com/p/33542591
A little bit of example code can make a question like this a lot easier to answer ... I've never used the sigaction API before but I threw this together -
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void segv_handler (int in)
{
puts ("in segv_handler()");
}
void sigbus_handler (int in)
{
puts ("in sigbus_handler()");
}
int main ()
{
struct sigaction action;
action.sa_mask = 0;
action.sa_flags = 0;
action.sa_handler = segv_handler;
sigaction (SIGSEGV, &action, NULL);
action.sa_handler = sigbus_handler;
sigaction (SIGBUS, &action, NULL);
puts ("about to send SIGSEGV signal from main()");
kill (getpid(), SIGSEGV);
puts ("about to send SIGBUS signal from main()");
kill (getpid(), SIGBUS);
puts ("exiting main()");
}
% lldb a.out
(lldb) br s -n main
(lldb) r
(lldb) pr h -p true -s false SIGSEGV SIGBUS
(lldb) c
Process 54743 resuming
about to send SIGSEGV signal from main()
Process 54743 stopped and restarted: thread 1 received signal: SIGSEGV
in segv_handler()
about to send SIGBUS signal from main()
Process 54743 stopped and restarted: thread 1 received signal: SIGBUS
in sigbus_handler()
exiting main()
Process 54743 exited with status = 0 (0x00000000)
(lldb)
Everything looks like it's working correctly here. If I'd added -n false to the process handle arguments, lldb wouldn't have printed the lines about Process .. stopped and restarted.
Note that these signal settings do not persist across process executions. So if you're starting your debug session over (r once you've already started the process once), you'll need to re-set these. You may want to create a command alias shortcut and put it in your ~/.lldbinit file so you can set the process handling the way you prefer with a short cmd.

Parent process not ending when using fork() and execl(...)

I'm new to programming with linux and I was trying to understand how fork() and exec functions work. To make it easier for myself, I created a simply Dummy executable (with gcc -o Dummy.exe ...) and tried to call fork function so I can replace the child with the Dummy.exe executable I have created.
The problem I'm coming accross is that when I run the code, it shows me the contents of the Dummy.exe, however, I don't see anything past that - meaning, I don't see the parent process ending.
When I run my code Ex1.cpp, I get the output:
Program is Running
--- ****** ---
Ended
me#mdev>
The only way I can get the program to end is by pressing return key - you will see a blank line after word Ended.
Here is the code in my Ex1.cpp
#include <iostream>
using namespace std;
int main()
{
pid_t retVal;
int newStatus;
switch(retVal = fork())
{
case -1:
cout<<"Error occured with fork"<<endl;
break;
case 0:
cout<<"Child forked"<<endl;
newStatus = execl("Dummy.exe","Dummy.exe", NULL);
break;
default:
cout<<"Parent has a new child: "<<retVal<<endl;
}
cout<<"Ended ..."<<endl;
return 0;
}
My Dummy.cpp code is below:
#include <iostream>
using namespace std;
int main()
{
cout<<"Program is Running"<<endl;
cout<<"--- ****** ---"<<endl;
cout<<"Ended"<<endl;
return 0;
}
My background is Windows development and all this is new for me - I appreciate your help.
#include <iostream>
using namespace std;
int main ()
{
pid_t retVal;
int newStatus;
int returnStatus;
if (retVal = fork() < 0)
{
cout << "Error on fork" << endl;
exit (1);
}
// Child process
else if (retVal == 0)
{
// No code is executed after an exec statement
newStatus = execl("./Dummy", "Dummy", NULL);
}
else
{
// This waits for the child to finish and clean up
waitpid(retVal, &returnStatus, NULL);
}
return returnStatus;
}
It is not a good idea to use a switch statement in your case since no code is executed after an exec statement. You can read up on that further by reading the man page at the command prompt by typing man 2 exec. Also it is always a good idea to wait for the child to exit successfully which is what the waitpid function does. Try this and let me know if it works and if you have any questions as well.

Resources