Application segmentation fault after rebuilding kernel

[settimid]

Hi all

I have a TC 3.8.4 with kernel 2.6.33.3-tinycore64 from here: http://distro.ibiblio.org/tinycorelinux/3.x/archive/3.8.4/distribution_files/ (file bzImage64)
All is fine, my C software run perfectly with this setup.

Now i try to rebuild kernel from source (as first step, without changing anything from its default)

Code: [Select]

wget http://distro.ibiblio.org/tinycorelinux/3.x/release/src/kernel/linux-2.6.33.3-patched.tbz2
wget http://distro.ibiblio.org/tinycorelinux/3.x/release/src/kernel/config-2.6.33.3-tinycore64
tar xf linux-2.6.33.3-patched.tbz2
cd linux-2.6.33.3
make mrproper
cp ../config-2.6.33.3-tinycore64 .config
make oldconfig
make

This create a bzImage under arch/x86/boot/bzImage that I copy as bzImage64 to replace the original one.

The OS boot up and all seem to be ok, except that if I run my C application i have a segmentation fault as soon as I call

Code: [Select]

gettimeofday() or

Code: [Select]

time() system function.

Googling about gettimeofday and segmentation fault this seem to be related to VDSO (Virtual Dynamically-linked Shared Object) https://man7.org/linux/man-pages/man7/vdso.7.html but I have no idea of how to solve this issue.

Any hint?

[curaga]

You also need to replace the modules if you used a different compiler version. Though your symptoms are rather curious, not sure what exactly is the cause.

[settimid]

Hi curaga, here is something more about my setup

I build kernel source (and my software as well) using a Suse 11.3 64bit, that run a very similar kernel (2.6.34 x86_64).
My C code is compiled with static linking (gcc -static) as per requirement.

You also need to replace the modules if you used a different compiler version. Though your symptoms are rather curious, not sure what exactly is the cause.

Yes, I imagine it could be something like this, but what do you exactly mean?
Should I replace modules in my target tinycore or in my build machine (or both) and what is the correct procedure to do this?

[curaga]

You only copied bzImage to the target. You also need to copy the modules, via the "make modules_install INSTALL_MOD_PATH=/tmp/foo" command; replace the old modules inside the initrd with those, maybe pack some into extensions if you want.

The cause of your crash however could be in suse's glibc. It's possible it was set to require 2.6.34, and crashing on 2.6.33 in a time func could be caused by that.
edit: Oh, I just re-read your post, and you said your program works fine with the original kernel.

[settimid]

You only copied bzImage to the target. You also need to copy the modules, via the "make modules_install INSTALL_MOD_PATH=/tmp/foo" command; replace the old modules inside the initrd with those, maybe pack some into extensions if you want.

Hi curaga
I tried to do as you suggest, i.e. compile the kernel modules and then update the microcore64.gz file by replacing the contents of the /lib/modules/2.6.33.3-tinycore64 folder (unpacking and packing it) but nothing changed.

[curaga]

Then it could be a compiler bug, something in that version of gcc miscompiling that version of kernel. But really hard to say.

[CentralWare]

You also need to replace the modules if you used a different compiler version. Though your symptoms are rather curious, not sure what exactly is the cause.

@settimid: Just for sake of curiosity:

• What version of TinyCoreLinux did you initially install on the device?
• Is there cause for why we're using version 3.x? (We're currently at 14.x)
• Is the device in question 64 bit (since your downloaded kernel config file is)

[gadget42]

@settimid: Just for sake of curiosity:
....
Is there cause for why we're using version 3.x?
....

also with reference to version 3.x(link to removal advisement/post):
https://forum.tinycorelinux.net/index.php/topic,26497.0.html

[CentralWare]

Thanks @gadget42, I still have yet to sync our mirror before the repo gets Spring Cleaning!

[settimid]

You also need to replace the modules if you used a different compiler version. Though your symptoms are rather curious, not sure what exactly is the cause.

@settimid: Just for sake of curiosity:

• What version of TinyCoreLinux did you initially install on the device?
• Is there cause for why we're using version 3.x? (We're currently at 14.x)
• Is the device in question 64 bit (since your downloaded kernel config file is)

Hi @CentralWare

• The working device is a Tinycore USB key running with microcore64.gz and bzImage64 from here http://distro.ibiblio.org/tinycorelinux/3.x/archive/3.8.4/distribution_files/
• Critical industrial applications do not easily accommodate upgrades.
• Yes, device in question is 64bit. uname say "TC 3.8.4 with kernel 2.6.33.3-tinycore64"

That said, I would now need to recompile the kernel in question to get motherboard buzzer support, which doesn't seem to be enabled by default.

I download kernel source and re-build kernel, with the procedure I wrote in my first post.
Then updated mu USB key with bzImage64 i build up and (as a second try) with the microcore64 re-packed with the modules I build.


OS boot up correctly, beep works, uname show correct information, but my C application suddenly crash (segfault)
If I comment out all call to gettimeofday() and time() system function my application run, but of course I need them.

I use a Suse 11.3 64bit, that run a very similar kernel (2.6.34 x86_64) to build both kernel and my application.

[settimid]

also with reference to version 3.x(link to removal advisement/post):
https://forum.tinycorelinux.net/index.php/topic,26497.0.html

@gadget42 Thank you very much for alerting me to this. I owe you a beer.

[Rich]

Hi settimid

... Critical industrial applications do not easily accommodate upgrades. ...

Understood. However, if TC4 is acceptable, it has the PC speaker enabled.

[curaga]

It's also likely that TC4's kernel would run fine on TC3, if you want to change only one component.

[Rich]

Hi curaga
TC3=2.6.33
TC4=3.0.21
Did those older kernels allow loading non-matching modules?

[curaga]

No, but I'd consider the kernel and modules one component in a sense. I did write a bit unclearly.