All Projects

IDCategoryTask TypePrioritySeveritySummaryReported InStatus
 3392 PackagesBug ReportVery LowLow valgrind: does not detect obvious memory leak TrunkClosed Task Description

I am running valgrind on OpenWrt trunk x86_64. The package provides valgrind 3.15.0. My OpenWrt install also makes use of musl.

I have the following test program, which has an obvious memory leak:

#include <stdio.h>
#include <stdlib.h>

int f(void) {
	char *buf = malloc(BUFSIZ);
	if (buf == NULL) {
		return -1;
	}
	return 0;
}

int main(void)
{
	f();
}

Running valgrind on OpenWrt produces this:

valgrind --leak-check=full ./leak
==22148== Memcheck, a memory error detector
==22148== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22148== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==22148== Command: ./leak
==22148== 
==22148== Conditional jump or move depends on uninitialised value(s)
==22148==    at 0x4019DDC: ??? (in /lib/libc.so)
==22148==    by 0x405AE5D: ??? (in /lib/libc.so)
==22148== 
==22148== Conditional jump or move depends on uninitialised value(s)
==22148==    at 0x401961F: ??? (in /lib/libc.so)
==22148==    by 0x405AE5D: ??? (in /lib/libc.so)
==22148== 
==22148== 
==22148== HEAP SUMMARY:
==22148==     in use at exit: 0 bytes in 0 blocks
==22148==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==22148== 
==22148== All heap blocks were freed -- no leaks are possible
==22148== 
==22148== Use --track-origins=yes to see where uninitialised values come from
==22148== For lists of detected and suppressed errors, rerun with: -s
==22148== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

There is no mention of the memory leak.

Here is the output I expect, as produced by running valgrind on Fedora:

valgrind --leak-check=full ./leak 
==7325== Memcheck, a memory error detector
==7325== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7325== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==7325== Command: ./leak
==7325== 
==7325== 
==7325== HEAP SUMMARY:
==7325==     in use at exit: 8,192 bytes in 1 blocks
==7325==   total heap usage: 1 allocs, 0 frees, 8,192 bytes allocated
==7325== 
==7325== 8,192 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7325==    at 0x483A809: malloc (vg_replace_malloc.c:307)
==7325==    by 0x401137: f (leak.c:5)
==7325==    by 0x401159: main (leak.c:14)
==7325== 
==7325== LEAK SUMMARY:
==7325==    definitely lost: 8,192 bytes in 1 blocks
==7325==    indirectly lost: 0 bytes in 0 blocks
==7325==      possibly lost: 0 bytes in 0 blocks
==7325==    still reachable: 0 bytes in 0 blocks
==7325==         suppressed: 0 bytes in 0 blocks
==7325== 
==7325== For lists of detected and suppressed errors, rerun with: -s
==7325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
3270PackagesBug ReportVery LowLowgcc: package seems incompatible with linker provided by...TrunkUnconfirmed Task Description

I use the gcc package to compile C code on my OpenWrt installation. Something has broken the toolchain, and it appears to be related to the binutils package that OpenWrt base provides. I receive errors such as these when I compile:

root@OpenWrt # gcc hello.c 
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libssp_nonshared.a(__stack_chk_fail_local.o): unable to initialize decompress status for section .debug_info
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libssp_nonshared.a(__stack_chk_fail_local.o): unable to initialize decompress status for section .debug_info
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info
/usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info

I was able to overcome this problem by updating binutils. I copied the version information and patches for binutils 2.32 from toolchain/binutils/ into package/devel/binutils/, and I built a newer version of the binutils package. Whereas the toolchain version of binutils provides the option to build a recent release, the package version is still 2.27.

See also https://github.com/openwrt/packages/issues/13019.


2581KernelBug ReportVery LowLowProcess umask ignored when serving NFSv4.2 shareTrunkUnconfirmed Task Description

I am not sure if this is a server-side or client-side problem.

I have an NFS share that I mount from a Fedora 31 workstation. When I mount the share using NFSv4.2, I find that the process umask is ignored when creating files and directories within the share. Files are created with 666 permissions, and directories are created with 777 permissions. Mounting the same share with NFSv4.1 rather than 4.2 works fine.

1. Mount an NFSv4.2 share from OpenWrt to /mnt on Fedora
2. mkdir /mnt/foo
3. ls -ld /mnt/foo

Resulting permissions are 777, but they should be 755, due to a process umask of 0022.

This seems related to a similar Ubuntu report:

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736

I suspect this results from changes due to the RFC “Allowing Inheritable NFSv4 ACLs to Override the Umask:”

https://tools.ietf.org/id/draft-ietf-nfsv4-umask-03.html

See also https://bugzilla.redhat.com/show_bug.cgi?id=1667761 for a report on the client side.

OpenWrt SNAPSHOT, r11219-34c4741da0 on x86_64
kmod-fs-nfs - 4.19.78-1
kmod-fs-nfs-common - 4.19.78-1
kmod-fs-nfs-common-rpcsec - 4.19.78-1
kmod-fs-nfs-v4 - 4.19.78-1
kmod-fs-nfsd - 4.19.78-1
nfs-kernel-server - 2.4.1-1
nfs-utils-libs - 2.4.1-1

2440Base systemBug ReportVery LowLowRaspberry Pi 3 build does not seem to run in QEMUTrunkUnconfirmed Task Description

I am interested in running a Raspberry Pi 3 OpenWrt image (built from commit 7ec092e6) in QEMU. My aim is to perform some testing of custom-built images before shipment. I am close to accomplishing this, but the kernel panics soon after booting.

I run QEMU With:

qemu-system-aarch64 -kernel build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/vmlinux -dtb build_dir/target-aarch64_cortex-a53_musl/linux-brcm2708_bcm2710/image-bcm2710-rpi-3-b.dtb -cpu cortex-a53 -m 256 -M raspi3 -append “root=/dev/sda2 rootfstype=ext4 rw” -hda openwrt-brcm2708-bcm2710-rpi-3-ext4-factory.img

The kernel crashes under these circumstances. I attached a screenshot I cobbled together that contains the kernel’s output.

I first mentioned this issue on the openwrt-devel mailing list (June 2, 2019, subject “Running Raspberry Pi 3 OpenWrt in QEMU”), and Petr ┼átetiar suggested I open a bug report here.


 1796 PackagesBug ReportVery LowLow e2fsprogs does not compile against glibc TrunkClosed Task Description

The e2fsprogs package fails to build when I configure the OpenWrt build process to produce an image for x86/x86_64 using glibc. I am using OpenWrt master as of commit d1ea8ac3b476e1e552f42dbf1042b521c57a0df4.

From what I can tell, a number of the programs in e2fsprogs need to link against -lpthread when using glibc. However, several Makefiles (for example, e2fsck/Makefile) contain the following:

      LIBCOM_ERR = $(LIB)/libcom_err.so # -lpthread

It looks like the ‘#’ character is a result of the definition of @PRIVATE_LIBS_CMT@ which autotools uses to transform MCONFIG.in into MCONFIG. This, in turn, seems to follow from the use of –enable-elf-shlibs in the OpenWrt package definition.

Here is the tail end of a failed build:

LD e2fsck
e2fsck.h:598:13: warning: type of ‘fatal_error’ does not match original declaration [-Wlto-type-mismatch]
extern void fatal_error(e2fsck_t ctx, const char * fmt_string);

           ^

util.c:53:6: note: ‘fatal_error’ was previously declared here
void fatal_error(e2fsck_t ctx, const char *msg)

    ^

util.c:53:6: note: code may be misoptimized unless -fno-strict-aliasing is used
jfs_user.h:208:17: warning: type of ‘e2fsck_global_ctx’ does not match original declaration [-Wlto-type-mismatch]
extern e2fsck_t e2fsck_global_ctx; /* Try your very best not to use this! */

               ^

e2fsck.h:221:31: note: type ‘struct e2fsck_struct *’ should match type ‘struct e2fsck_struct *’ typedef struct e2fsck_struct *e2fsck_t;

                             ^

unix.c:68:10: note: ‘e2fsck_global_ctx’ was previously declared here
e2fsck_t e2fsck_global_ctx; /* Try your very best not to use this! */

        ^

unix.c:68:10: note: code may be misoptimized unless -fno-strict-aliasing is used
../lib/libcom_err.so: undefined reference to `sem_post’ ../lib/libcom_err.so: undefined reference to `sem_wait’ ../lib/libcom_err.so: undefined reference to `sem_init’ ../lib/libcom_err.so: undefined reference to `sem_destroy’ collect2: error: ld returned 1 exit status

Showing tasks 1 - 5 of 5 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing