Bug 5096 - Value too large for defined data type
Summary: Value too large for defined data type
Status: RESOLVED DUPLICATE of bug 6908
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.19.x
Hardware: All Other
: P5 critical
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-13 17:57 UTC by David
Modified: 2014-02-25 12:30 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:


Attachments
config (23.99 KB, application/octet-stream)
2012-04-13 17:57 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2012-04-13 17:57:49 UTC
Created attachment 4268 [details]
config

I just cross compiled busybox (android 4.0.4) v1.19.4

that's the error I get:
I//system/xbin/busybox(  109): run-part:s /system/etc/init.d: Value too large for defined data type
I/logwrapper(  109): /system/xbin/busybox terminated by exit(0)

in the config (attached) CONFIG_LFS is set to Y.

reading about on some forums over the net seems to be a busybox bug.

my linuxbox: ubuntu 11.04 x64

(sorry for my english)
Comment 1 David 2012-04-22 08:50:14 UTC
> I//system/xbin/busybox(  109): run-parts: /system/etc/init.d: Value too large for defined data type
> I/logwrapper(  109): /system/xbin/busybox terminated by exit(0)

bug still exist in the v1.20 stable
Comment 2 Denys Vlasenko 2012-06-21 07:33:02 UTC
(In reply to comment #0)
> Created attachment 4268 [details]
> config
> 
> I just cross compiled busybox (android 4.0.4) v1.19.4
> 
> that's the error I get:
> I//system/xbin/busybox(  109): run-part:s /system/etc/init.d: Value too large
> for defined data type

I believe that's E2BIG error returned by one of system calls.

Can you strace the run-parts invocation which causes this, and show its command line and input data (the file inside /system/etc/init.d which causes this)?
Comment 3 camelot 2012-12-02 19:49:44 UTC
BusyBox v1.20.2 shows "Value too large for defined data type" by "df" applet.
This only if a dav2fs share is mounted. This worked some while ago


strace -f /bin/df
...
statfs("/proc/fs/nfsd", {f_type=0x6e667364, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0}) = 0
statfs("/var/media/autofs", {f_type=0x187, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0}) = 0
statfs("/var/media/autofs/GMX", 0x7fb59f28) = -1 EOVERFLOW (Value too large for defined data type)
brk(0x49f000)                           = 0x49f000
brk(0x4a0000)                           = 0x4a0000
write(2, "df: /var/media/autofs/GMX: Value"..., 65df: /var/media/autofs/GMX: Value too large for defined data type
) = 65
read(3, "", 4096)                       = 0
close(3)                                = 0
exit(1)                                 = ?
Comment 4 camelot 2012-12-04 14:06:20 UTC
addition to my last comment:
I "fixed" the problem by removing some files. 100% (or more) of 1GB space were used. Now 24% and the problem is gone  -.-
Comment 5 Denys Vlasenko 2012-12-05 01:18:24 UTC
(In reply to comment #3)
> BusyBox v1.20.2 shows "Value too large for defined data type" by "df" applet.
> This only if a dav2fs share is mounted. This worked some while ago
> 
> 
> strace -f /bin/df
> ...
> statfs("/proc/fs/nfsd", {f_type=0x6e667364, f_bsize=4096, f_blocks=0,
> f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0}) = 0
> statfs("/var/media/autofs", {f_type=0x187, f_bsize=4096, f_blocks=0, f_bfree=0,
> f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=0}) = 0
> statfs("/var/media/autofs/GMX", 0x7fb59f28) = -1 EOVERFLOW (Value too large for
> defined data type)

Hmm.
The problem is that it uses statfs syscall, not statfs64.
But C source uses statfs _function_ call, not _syscall_,
it's the duty of libc to use correct _syscall_.

I just verified on my machine that glibc uses statfs64 syscall
to implement statfs (with LFS=y), but, for example, uclibc
uses statfs (and is probably prone to the same failure you see).
Comment 6 Denys Vlasenko 2014-02-25 12:30:17 UTC

*** This bug has been marked as a duplicate of bug 6908 ***