I was trying to add a .so file into /system/lib with PRODUCT_COPY_FILES, but once I try to build it it fails with this error:
ExternalError: Failed to run command '['lpmake', '--metadata-size', '65536', '--super-name', 'system', '--metadata-slots', '2', '--auto-slot-suffixing', '--device', 'system:2952790016', '--device', 'vendor:805306368', '--device'
, 'product:314572800', '--group', 'google_dynamic_partitions:4069523456', '--partition', 'system:readonly:2344202240:google_dynamic_partitions', '--image', 'system=/home/markus/EPhone/ethOS/out/target/product/blueline/obj/PACKAG
ING/target_files_intermediates/lineage_blueline-target_files-eng.markus/IMAGES/system.img', '--partition', 'vendor:readonly:452227072:google_dynamic_partitions', '--image', 'vendor=/home/markus/EPhone/ethOS/out/target/product/bl
ueline/obj/PACKAGING/target_files_intermediates/lineage_blueline-target_files-eng.markus/IMAGES/vendor.img', '--partition', 'product:readonly:1016426496:google_dynamic_partitions', '--image', 'product=/home/markus/EPhone/ethOS/o
ut/target/product/blueline/obj/PACKAGING/target_files_intermediates/lineage_blueline-target_files-eng.markus/IMAGES/product.img', '--partition', 'system_ext:readonly:266698752:google_dynamic_partitions', '--image', 'system_ext=/
home/markus/EPhone/ethOS/out/target/product/blueline/obj/PACKAGING/target_files_intermediates/lineage_blueline-target_files-eng.markus/IMAGES/system_ext.img', '--sparse', '--output', '/home/markus/EPhone/ethOS/out/target/product
/blueline/obj/PACKAGING/target_files_intermediates/lineage_blueline-target_files-eng.markus/OTA']' (exit code 70):
lpmake I 12-25 19:38:11 10456 10456 builder.cpp:1031] [liblp]Partition system will resize from 0 bytes to 2344202240 bytes
lpmake I 12-25 19:38:11 10456 10456 builder.cpp:1031] [liblp]Partition vendor will resize from 0 bytes to 452227072 bytes
lpmake I 12-25 19:38:11 10456 10456 builder.cpp:1031] [liblp]Partition product will resize from 0 bytes to 1016426496 bytes
lpmake E 12-25 19:38:11 10456 10456 builder.cpp:620] [liblp]Partition system_ext is part of group google_dynamic_partitions which does not have enough space free (266698752 requested, 3812855808 used out of 4069523456)
Not enough space on device for partition system_ext with size 266698752
How can I increase the space on system_ext, so I can include the .so file?
I guess you need to change BoardConfig file, similar to https://github.com/LineageOS/android_device_google_crosshatch/commit/155109c657c804ca14e4cbb78ddc2caf5bfeda46 but for BOARD_SYSTEM_EXTIMAGE_PARTITION_RESERVED_SIZE (just in case if you need to change BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE later).
FYI blueline is built on crossnatch product tree.
Related
The Microsoft Windows Dev Center Dashboard lets me collect stack traces from failures in my native desktop app in the wild.
Unfortunately, minidumps aren't avaialble. I just get a TSV file that (sometimes) has a stack trace in it, which looks like this:
Frame Image Function Offset
0 MyApp 0x2F59A1
1 MyApp 0x11CEA8
2 MyApp 0x11AE74
3 MyApp 0x151289
4 MyApp 0x2A686
5 MyApp 0x180720
6 MyApp 0x1807B6
7 MyApp 0x2E875A
8 MyApp 0x2E8882
9 kernel32 BaseThreadInitThunk 0x24
10 ntdll __RtlUserThreadStart 0x2B
11 ntdll _RtlUserThreadStart 0x1B
To make this uesful, I load the matching binary in WinDbg, figure out the offset plus the base address, and unassemble at the resulting address. If my app loads at 0x00400000, I add 0x2F59A1 to it and get 0x006F59A1. Unassembling there shows me the return address of that stack frame, so I can get some idea of what the crash is about.
Is there a better way? How can I request minidumps from Dev Center? (Microsoft Support says I just can't. Really?) Is there a script to convert at TSV file a usable stack trace so I don't manually evaluate each stack frame? Is there some other way?
I don't know if you can get a .dmp or not google says you can not get one from dash board
the answer below is a modified version of a script
I once used it to disassemble # .map file offsets improvise if needed
it takes the offsets from the column using pandas
creates a command string and uses subprocess to disassemble at that offset
i assume the tsv is a tab seperated value file if not you have some tweaking to do
assuming tab seperated file with data like below
Frame Image Function Offset
0 calc 0x1012
0 calc 0x1015
you can automate the process with some for loops in the code below
edit since i do two subprocess calls the offsets for both forward and backward disassembly are different (ASLR effect )
:\>cat Untitled.py
import pandas as pd
df = pd.read_csv("tsv.txt" , delimiter='\t')
print df
offset = df.Function.unique()[1]
print offset
import subprocess
cmdline = "cdb -c \"ub calc+"+offset+";q\" calc.exe | tail"
print cmdline
output = subprocess.check_output(cmdline ,shell=True )
print output
cmdline = "cdb -c \"u calc+"+offset+";q\" calc.exe | tail"
print cmdline
output = subprocess.check_output(cmdline ,shell=True )
print output
:\>python Untitled.py
Frame Image Function Offset
0 0 calc 0x1012 NaN
1 0 calc 0x1015 NaN
0x1015
cdb -c "ub calc+0x1015;q" calc.exe | tail
calc!_imp__SHGetFolderPathW+0x1:
00f31005 57 push edi
00f31006 1f pop ds
00f31007 7629 jbe calc!_imp__GdipCloneImage+0x2 (00f31032)
00f31009 a1237683dd mov eax,dword ptr ds:[DD837623h]
00f3100e 27 daa
00f3100f 7646 jbe calc!_imp__GdipDeleteGraphics+0x3 (00f31057)
00f31011 1e push ds
00f31012 197600 sbb dword ptr [esi],esi
quit:
cdb -c "u calc+0x1015;q" calc.exe | tail
calc!⌂SHELL32_NULL_THUNK_DATA+0x1:
009b1015 0000 add byte ptr [eax],al
009b1017 007a41 add byte ptr [edx+41h],bh
009b101a 5f pop edi
009b101b 7700 ja calc!⌂SHLWAPI_NULL_THUNK_DATA+0x1 (009b101d)
009b101d 0000 add byte ptr [eax],al
009b101f 005fa1 add byte ptr [edi-5Fh],bl
009b1022 687449a568 push 68A54974h
009b1027 744a je calc!_imp__GdiplusShutdown+0x3 (009b1073)
quit:
:\>
How to edit or add exif metadata by graphicsmagick command? I've tried the following:
gm convert -set EXIF:XPKeywords "bird, sleep, moon" bird.jpg bird2.jpg
My command is executing successfully and the image is creating but the exif metadata is not updating.
I don't believe you can do that with GraphicsMagick, and I would suggest exiv2 like this:
exiv2 -M"add Exif.Image.XPKeywords Ascii 'bird,sleep,moon'" image.jpg
Then you can view them with jhead too:
jhead -v image.jpg
JFIF SOI marker: Units: 0 (aspect ratio) X-density=1 Y-density=1
Exif header 50 bytes long
Exif section in Intel order
(dir has 1 entries)
Windows-XP keywords = "bird,sleep,moon"
Approximate quality factor for qtable 0: 92 (scale 16.28, var 1.13)
Approximate quality factor for qtable 1: 92 (scale 16.20, var 0.15)
JPEG image is 2000w * 2000h, 3 color components, 8 bits per sample
File name : image.jpg
File size : 6968929 bytes
File date : 2015:10:20 09:23:24
Resolution : 2000 x 2000
Trying to run blinky sample for Atmel sam3s and inspecting the stack pointer...
SP has the value 0x20000238 at the start of main function which is equal too Ram base + RW + ZI for this sample.
The base RAM address for this chip is : 0x20000000
Total ram size is: 0x10000
I expected the sp to be initialized on 0x20010000 and coming down.
Can anyone explain if I am wrong or not?
As Pait said (he/she should have answered the question so I could accept it, I think),
I was wrong to think the stack will be placed at the end of RAM by default. But I think it is wise to make it be placed there.
This is how I do it for my SAM3S micro, by changing the scatter file
LR_IROM1 0x00400000 0x00080000 { ; load region size_region
ER_IROM1 0x00400000 0x00080000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM1 0x20000000 0x00010000 { ; RW data
.ANY (+RW +ZI)
}
RW_STACK 0x2000C000 UNINIT 0x4000 { ; STACK data
*.o (STACK)
}
}
RAM base = 0x20000000
Total RAM = 64 kb
Intended stack size = 16 kb
I'm using QtEmbedded (4.8.0) on an ARM display device with 16bits color depth on the framebuffer (/dev/fb0). At this scenario we are getting the colors bits RED and BLUE exchanged.
We are using the following compile flags:
./configure -embedded arm -xplatform qws/linux-arm-gnueabi-g++ -prefix /home/rchaves/Toolchain -release -opensource -shared -fast -depths 16 -largefile -no-exceptions -no-accessibility -stl -no-sql-mysql -no-sql-psql -no-sql-oci -no-sql-odbc -no-sql-tds -no-sql-db2 -no-sql-sqlite -no-sql-sqlite2 -no-sql-ibase -no-qt3support -no-xmlpatterns -no-multimedia -no-audio-backend -no-phonon-backend -no-svg -no-webkit -no-javascript-jit -no-script -no-scripttools -no-declarative -no-declarative-debug -qt-zlib -qt-libtiff -qt-libpng -qt-libmng -qt-libjpeg -no-openssl -no-nis -no-cups -iconv -no-pch -no-dbus -qt-freetype -no-opengl -qt-gfx-linuxfb -qt-kbd-linuxinput -qt-mouse-tslib -nomake demos -nomake examples
And the following parameters to execute the application:
QWS_DISPLAY=LinuxFb:/dev/fb0:depth=16 ./app -qws
Here there are the application framebuffer (samples) log:
The framebuffer device was opened successfully.
Fixed screen info:
id: DISP3 BG
smem_start: 0x93800000
smem_len: 7864320
type: 0
type_aux: 0
visual: 2
xpanstep: 1
ypanstep: 1
ywrapstep: 0
line_length: 2048
mmio_start: 0x0
mmio_len: 0
accel: 0
The framebuffer device was mapped to memory successfully.
Successfully switched to graphics mode.
Variable screen info:
xres: 1024
yres: 768
xres_virtual: 1024
yres_virtual: 3840
yoffset: 0
xoffset: 0
bits_per_pixel: 16
grayscale: 0
red: offset: 0, length: 5, msb_right: 0
green: offset: 5, length: 6, msb_right: 0
blue: offset: 11, length: 5, msb_right: 0
transp: offset: 0, length: 0, msb_right: 0
nonstd: 0
activate: 64
height: -1
width: -1
accel_flags: 0x0
pixclock: 15385
left_margin: 157
right_margin: 157
upper_margin: 16
lower_margin: 15
hsync_len: 5
vsync_len: 1
sync: 0
vmode: 0
Frame Buffer Performance test...
Average: 43020 usecs
Bandwidth: 174.338 MByte/Sec
Max. FPS: 23.245 fps
Will draw 3 rectangles on the screen,
they should be colored red, green and blue (in that order).
Done.
Better late than never. I had this exact problem with a SAM5 processor using Qt5.5.1 and the linuxfb plugin. Reconfigure or recompile the Qt5 framework will NOT solve the problem.
Apparently the LinuxFB plugin does not support the BGR format. There is an open bug tracking this issue. Check the determineFormat function in ../src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp, in which you will find out that the ImageFormats are hardcoded to **RGB no matter what kind of framebuffer info was provided.
To solve the problem, applying the patch attached to the bug may help you to resolve this issue.
I said "may" because my framebuffer driver was falsely reporting it is in the RBG format. So watch out for that. If that is the case, just hardcode the swapRgb flag until you fix your framebuffer driver.
Update: Try setting -depths generic in ./configure and run with -display linuxfb:genericcolors. This is as per this thread which discusses the problem.
Old answer: It sounds like your endian-ness of the display is swapped.
As per the documentation, you can try to pass the littleendian option to the display string. The other option is to consult the linux fb documentation about performing endian swaps.
I traced an oracle process, and find it first open a file /etc/netconfig as file handle 11, and then duplicate it as 256 by calling fcntl with parameter F_DUPFD, and then close the original file handle 11. Later it read using file handle 256. So what's the point to duplicate the file handle? Why not just work on the original file handle?
12931: 0.0006 open("/etc/netconfig", O_RDONLY|O_LARGEFILE) = 11
12931: 0.0002 fcntl(11, F_DUPFD, 0x00000100) = 256
12931: 0.0001 close(11) = 0
12931: 0.0002 read(256, " # p r a g m a i d e n".., 1024) = 1024
12931: 0.0003 read(256, " t s t p i _ c".., 1024) = 215
12931: 0.0002 read(256, 0x106957054, 1024) = 0
12931: 0.0001 lseek(256, 0, SEEK_SET) = 0
12931: 0.0002 read(256, " # p r a g m a i d e n".., 1024) = 1024
12931: 0.0003 read(256, " t s t p i _ c".., 1024) = 215
12931: 0.0003 read(256, 0x106957054, 1024) = 0
12931: 0.0001 close(256) = 0
On some systems, like Solaris, standard I/O with FILE only works with file descriptors 0-255 because its implementation of the FILE structure uses an 8-bit integer instead of int. If a program uses a lot of file descriptors, it's useful to reserve file descriptors 3-255 using fnctl(fd, F_DUPFD, 256). Otherwise, functions like fopen(), freopen() and fdopen() will fail if you have 256 files open.
As an aside, they're file descriptors rather than file handles. The latter are a C feature used with fopen and its brethren while descriptors are more UNIXy, for use with open et al.
Interesting. The only reason that comes to mind is that some other piece of code has a specific need for the file descriptor to be 256. I suspect only Oracle would know the bizarre reasons for that. In any case, you're not guaranteed to get 256, you get the file first available file descriptor greater than or equal to that number.
From a bit of investigation (I don't know every little thing about the innards of UNIX off the top of my head), there are attributes that belong to a group of duplicated descriptors such as file position and access mode. There are other attributes that belong to a single file descriptor, even when duplicated, such as the close-on-exec flag in GNULib.
Doing a duplicate (either with dup, dup2 or your fcntl) could be a way to create two descriptors, one with different file descriptor attributes, but I can't see that being the case in your question since the first descriptor is closed anyway. As you say, why not just use the low descriptor?
Interestingly enough, if you google for netconfig f_dupfd, you will see similar traces where the fcntl fails and it continues to read that file with the low descriptor so my thoughts on the matter are that this is an attempt to preserve low file descriptors as much as possible. For example:
4327: open("/etc/netconfig", O_RDONLY|O_LARGEFILE) = 4
4327: fcntl(4, F_DUPFD, 0x00000100) Err#22 EINVAL
4327: read(4, " # p r a g m a i d e n".., 1024) = 1024
4327: read(4, " t s t p i _ c".., 1024) = 215
4327: read(4, 0x00296B80, 1024) = 0
4327: lseek(4, 0, SEEK_SET) = 0
4327: read(4, " # p r a g m a i d e n".., 1024) = 1024
4327: read(4, " t s t p i _ c".., 1024) = 215
4327: read(4, 0x00296B80, 1024) = 0
4327: close(4) = 0
Maybe the software has a byte array of file descriptors somewhere that's limited so it attempts to move other files above the 255-limit.
But really, that's just guesswork on my part (although I'd like to think it's relatively intelligent guesswork). Also keep in mind that it may not be Oracle itself doing this. The netconfig stuff is used in a lot of places so it may be some underlying library doing that, especially in light of the fact that most of the afore-mentioned web hits weren't Oracle-specific (ftp, remsh and so on).
Here is another example when a technique of reserving low-numbered file descriptors is needed.
Assume that a process opens a large number of file descriptor e.g. it accepts more than 1024 simultaneous socket connections. At the same time the process also uses third party library that opens socket connections and uses select() to see if sockets are ready for reading or writing. Additionally the third party library was compiled with __FD_SETSIZE set to 1024 (default value).
If the library opens a socket when all file descriptors below 1024 are in use then it will get a descriptor that select() and associated FD_* macros can not cope with. This will result in process crashing or undefined behaviour.