Why am I getting a "ScriptC sym lookup failed" error? - renderscript

I am trying to implement a simple luminance histogram in RenderScript using the
atomic arithmetic function rsAtomicInc,
but I get a runtime error which seems to say that function does not exist:
ScriptC sym lookup failed for _Z11rsAtomicIncPVj.
(To verify that this is the correct symbol, you can use:
$ echo "unsigned int __attribute__((overloadable))
rsAtomicInc ( volatile unsigned int *addr ) { return 0; }" > rsai.c
$ clang -c rsai.c; nm rsai.o
dumpbin can be substituted for nm on
Windows.) I have tried using the other atomic functions, which yield similar errors. I get the errors regardless of whether I use them in a kernel or an invokable function.
// histogram.rs:
#pragma version(1)
#pragma rs java_package_name(com.example.android.rs.hellocompute)
#pragma rs_fp_imprecise //relax math- allows NEON and other optimizations
const static float3 gMonoMult = {0.299f, 0.587f, 0.114f};
volatile uint32_t *luminanceHistogram;
void luminance(const uchar4 *img, const void *usrData, uint32_t x, uint32_t y) {
float4 f4 = rsUnpackColor8888(*img);
float3 mono = dot(f4.rgb, gMonoMult);
uchar lum = rsPackColorTo8888(mono).r;
rsAtomicInc(luminanceHistogram + lum);
}
void increment(int lum) {
rsAtomicInc(luminanceHistogram + lum);
}
// HelloCompute.java
int[] luminance = new int[256];
Allocation luminanceHistogram = Allocation.createSized(mRS,
Element.U32(mRS), luminance.length);
ScriptC_histogram histo = new ScriptC_histogram(mRS); // ERROR
Error log:
E/bcc ( 3539): Invalid RS info file /data/data/com.example.android.rs.hellocompute/cache/com.android.renderscript.cache/histogram.o.info! (No such file or directory)
E/RenderScript( 3539): ScriptC sym lookup failed for _Z11rsAtomicIncPVj
E/bcc ( 3539): Some symbols are found to be undefined during relocation!
E/bcc ( 3539): Error occurred when performs relocation on /data/data/com.example.android.rs.hellocompute/cache/com.android.renderscript.cache/histogram.o!
E/RenderScript( 3539): bcc: FAILS to prepare executable for 'histogram'
D/AndroidRuntime( 3539): Shutting down VM
W/dalvikvm( 3539): threadid=1: thread exiting with uncaught exception (group=0x415c6700)
E/AndroidRuntime( 3539): FATAL EXCEPTION: main
E/AndroidRuntime( 3539): android.renderscript.RSRuntimeException: Loading of ScriptC script failed.
E/AndroidRuntime( 3539): at android.renderscript.ScriptC.<init>(ScriptC.java:60)
...
The first error concerning histogram.o.info is probably spurious- a complete uninstall of the app makes it (but none of the other errors) go away for the first run.

This looks like a bug on our part (Android RenderScript team). It looks like those functions just don't exist in our implemented runtime library (even though they exist in the header). I will file a bug internally and get this cleaned up for future releases.

Related

CreateFile path not found error on a listed USB device with interface

Please help!
I'm trying to open a USB connection to an existing device with a listed active interface.
For that I need to open a file using a device id (path).
But CreateFile() fails with ERROR_PATH_NOT_FOUND (error code 3).
I got the following device ids from the Windows 10 Device Manager on my computer ...
"USB\VID_046D&PID_C534&MI_00\6&168DEF1E&0&0000"
"USB\VID_046D&PID_C534&MI_01\6&168DEF1E&0&0001"
"USB\VID_04F2&PID_B5EE&MI_00\6&237200EE&0&0000"
... and ran the following trivial program using one of them as input to CreateFile():
#include "..\..\test_wconsole\test_wconsole\_wconsole_.h"
#include "conio.h"
int APIENTRY wWinMain(_In_ HINSTANCE hi, _In_opt_ HINSTANCE hpi, _In_ LPWSTR c, _In_ int cs)
{
const WCHAR* path = L"USB\\VID_046D&PID_C534&MI_01\\6&168DEF1E&0&0001";
wcprintf("\nopening file \"%ws\" ... ", path);
HANDLE h_usbdevice = CreateFile
(
path,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING, FILE_FLAG_OVERLAPPED,
NULL
);
if (h_usbdevice != INVALID_HANDLE_VALUE) wcprintf("done\n"); else wcprintf("error %lu\n", GetLastError());
{ wcprintf("\n\tPress any key to proceed ... "); wcprintf("%i\n\n", _getch()); }
return NULL;
}
Here is a copy of the program’s console output:
opening file "USB\VID_046D&PID_C534&MI_01\6&168DEF1E&0&0001" ... error 3
Press any key to proceed ...
Running the program with Administrator privileges yields the same result. What am I doing wrong?

Including edk2-libc in efi shell application

How would one approach adding support for https://github.com/tianocore/edk2-libc, say I want to include stdio and use printf in my edk2 application? I followed StdLib/Readme.txt, and am able to successfully build examples in the AppPkg, however, when I try to add StdLib to my project I get errors like these:
LibString.lib(Searching.obj) : error LNK2005: strspn already defined in LibString.lib(Searching.obj)
LibCtype.lib(CClass.obj) : error LNK2005: isspace already defined in LibCtype.lib(CClass.obj)
(...)
LibC.lib(Main.obj) : error LNK2001: unresolved external symbol main
I do have the boilerplate (!include StdLib/StdLib.inc) added to my dsc file and in inf, I have StdLib.dec added to Packages and LibC and LibStdio added to LibraryClasses. I am using VS2017 toolchain for compilation and am using edk2-stable202108 release.
I was able to achieve this using below configuration for Hello Application of AppPkg.
Hello.inf
[Defines]
INF_VERSION = 0x00010006
BASE_NAME = Hello
FILE_GUID = a912f198-7f0e-4803-b908-b757b806ec83
MODULE_TYPE = UEFI_APPLICATION
VERSION_STRING = 0.1
ENTRY_POINT = ShellCEntryLib
#
# VALID_ARCHITECTURES = IA32 X64
#
[Sources]
Hello.c
[Packages]
MdePkg/MdePkg.dec
ShellPkg/ShellPkg.dec
StdLib/StdLib.dec
[LibraryClasses]
UefiLib
ShellCEntryLib
BaseLib
BaseMemoryLib
MemoryAllocationLib
LibStdLib
LibStdio
LibString
DevConsole
Hello.c
#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>
#include <stdio.h>
int
main (
IN int Argc,
IN char **Argv
)
{
printf("Hello, world!\n");
return 0;
}
What I have understood is that LibC has ShellAppMain() defined in it which internally calls extern main(). So You need to provide definition of main() in your source just like I did in Hello.c

Retrieving of PostgreSQL native error code

I have installed unixODBC-2.3.1-4.95.x86_64 on my SLES 12 machine and writing some application. But I faced with problem of error handling in PosgreSQL using unixODBC.
To do this I created the following function:
void checkDiag (SQLSMALLINT handleType, SQLHANDLE handle)
{
SQLRETURN rc = SQL_ERROR;
SQLCHAR sqlState[6];
SQLINTEGER nError;
SQLSMALLINT recnum = 0;
SQLCHAR eMsg[SQL_MAX_MESSAGE_LENGTH];
SQLCHAR nativeError[SQL_MAX_MESSAGE_LENGTH];
while (rc != SQL_NO_DATA_FOUND)
{
rc = SQLGetDiagRec (handleType,
handle,
recnum,
sqlState,
&nError,
eMsg,
255,
NULL);
if (rc != SQL_NO_DATA_FOUND)
{
SQLGetDiagField(handleType,
handle,
recnum,
SQL_DIAG_NATIVE,
nativeError,
255,
NULL);
printf("RECNUM %d\n sqlState = %s\n nError = %d\n Error Message %s\n nativeError %s \n",
recnum, sqlState, nError, (char *) eMsg, (char *)nativeError);
}
recnum++;
}
}
I have been trying to use different variants of diagId in SQLGetDiagField : SQL_DIAG_MESSAGE_TEXT, SQL_DIAG_NATIVE, SQL_DIAG_SQLSTATE.
I got everything but not PostgreSQL error Id.
I am constantly getting Postgresql error code id = -1.
So my question is:
Is it possible to get native PostgreSQL error code id using unixODBC API ?
Could you please tell me what I am doing wrong?
I found a solution.
The contents of the config file odbcinst.ini was the following:
[PostgreSQL]
Description=PostgreSQL ODBC driver
Driver=/usr/lib64/unixODBC/libodbcpsql.so
FileUsage=1
After I changed the description of Driver entry in the configuration file I was able to get PostgreSQL native error code.
[PostgreSQL]
Description=PostgreSQL ODBC driver
Driver=/opt/PostgreSQL/psqlODBC/lib/psqlodbcw.so
FileUsage=1
psqlodbcw.so library is supplied by EnterpriseDB PostgreSQL which can be downloaded here https://www.postgresql.org/download/linux/suse/ .
After these modifications I can get native error code. Using the code provided above, the postgres error code value will be written into sqlState.

gmake: a target completes but $(realpath ...) doesn't find it

Environment stuff:
Solaris NFS file servers running NFS 3
Errors occur in Linux or Solaris environments
Using GNU Make 3.82
Using Sun Studio compilers, if that matters
This is a vastly simplified example of the build I'm looking at:
all: ${list of shared objects to build}
#do whatever
lib1.so: ${1s objects}
lib2.so: ${2s objects}
lib3.so: ${3s objects}
#...
%.so:
$(call CHECK_DEPENDENCIES_EXIST)
#${LD} ${LDFLAGS} ${^} -o ${#}
%.o : %.c
#do stuff
%.o : %.cc
#do stuff
define CHECK_DEPENDENCIES_EXIST =
$(if $(realpath ${^}),,$(warning No dependencies specified for ${#})false)
endef
The short & sweet: $(realpath x y z) (x/y/z get returned if they exist; returns an absolute path including no symlinks) is removing files from the list under some circumstances, and I think it has to do with NFS. It isn't predictable which target will fail. Sometimes a target will fail when it's succeeded the last 10 times. If I take #false out of the macro, the build continues without error -- that is, the linker does not complain about the supposedly missing file(s).
I'll spare you the drawn-out explanation; suffice it to say, the macro is helpful for debugging.
Turns out there's a bug in gmake. From the GNU Make 3.82 source, function.c, on or about line 2026:
while ((path = find_next_token (&p, &len)) != 0 ) {
/* ... */
if (
#ifdef HAVE_REALPATH
realpath (in, out)
#else
abspath (in, out) && stat (out, &st) == 0
#endif
)
{
/* ... */
}
}
}
/* ... */
Ocasionally, various calls to realpath would get interrupted (EINTR); nothing in this code checks errno, so it just silently fails.
So, it wasn't that the file didn't exist, it was that $(realpath ...) was being interrupted by a signal (presumably a child instance of gmake signaling its completion or something similar) and this function wasn't designed to recover from that sort of event.
To fix the problem:
while ((path = find_next_token (&p, &len)) != 0 ) {
... becomes:
while ( errno == EINTR || (path = find_next_token (&p, &len)) != 0 ) {
The || will shortcut & prevent it from marching on to the next token.

Windbg Dump Generated programmatically can't be Debugged

I have a simple program:
int ExecuteCommand(wchar_t* commandLine)
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
BOOL bRet;
DWORD lpExitCode;
memset(&si, 0, sizeof(si));
si.cb = sizeof(si);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;
bRet = CreateProcess(
NULL, // pointer to name of executable module
commandLine, // pointer to command line string
NULL, // process security attributes
NULL, // thread security attributes
FALSE, // handle inheritance flag
NORMAL_PRIORITY_CLASS, // creation flags
NULL, // pointer to new environment block
NULL, // pointer to current directory name
&si, // pointer to STARTUPINFO
&pi // pointer to PROCESS_INFORMATION
);
if(bRet) WaitForSingleObject(pi.hProcess, INFINITE); // wait for process to finish
GetExitCodeProcess(pi.hProcess, &lpExitCode);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return lpExitCode;
}
void CreateCoreDump()
{
wchar_t buffer[256];
wsprintf(buffer, _T("windbg -p %d -c \".dump /mfh /u C:\\Tmp\\crashdump.dmp\""), GetCurrentProcessId());
ExecuteCommand(buffer);
}
DWORD ExceptionFilter()
{
CreateCoreDump();
return EXCEPTION_CONTINUE_SEARCH;
}
int _tmain(int argc, _TCHAR* argv[])
{
__try
{
int* p = NULL;
*p = 100;
}
__except(ExceptionFilter())
{
}
return 0;
}
It will generate a core dump when there is an exception, using function CreateCoreDump. Although the dump file could be generated successfully, it seems useless:
If I open this dump file using windbg, there is nothing in call stack!!!
But, if I debug this application directly in windbg, and set breakpoint at the line of calling CreateCoreDump, and then run windbg command:
.dump /mfh C:\Tmp\mydump.dmp
Open this dump file with WinDbg, I can see the full call stack.
Did I do something wrong, either in generating the dump file, or debugging the dump file using windbg?
When you attach the debugger after the exception happens, the debugger does not see the exception event. It creates a thread that has a breakpoint so the stack on that thread looks something like this:
0:001> kc
Call Site
ntdll!DbgBreakPoint
ntdll!DbgUiRemoteBreakin+0x38
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d
If you manually set the current thread to thread 0 (use ~0s) you will see your stack
0:001> ~0s
ntdll!ZwWaitForSingleObject+0xa:
00000000`76e5135a c3 ret
0:000> kc
Call Site
ntdll!ZwWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
tmp!ExceptionFilter
tmp!main$filt$0
ntdll!__C_specific_handler
ntdll!RtlpExecuteHandlerForException
ntdll!RtlDispatchException
ntdll!KiUserExceptionDispatch
tmp!main
tmp!__mainCRTStartup
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
When you start your program under the debugger two things happen, first, there is only one thread, and second the debugger knows about the exception so it will print something like this:
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
which tells you that you need to use the .ecxr commmand to get to the interesting thread. In this case you do not need to because the current debugger thread is already the one you want.
You have to add the exception record to the dump. For instance, I changed your sample to retrieve the exception information in the filter and pass it on the command line when generating the dump.
void CreateCoreDump(LPEXCEPTION_POINTERS p)
{
wchar_t buffer[256];
// I used the command line debugger, cdb, and added a "qd" command for it to exit after dumping.
wsprintf(buffer, _T("cdb.exe -p %d -c \".dump /mfh /u /xt 0x%x /xp 0x%p C:\\Tmp\\crashdump.dmp\";qd"), GetCurrentProcessId(), GetCurrentThreadId(), p);
ExecuteCommand(buffer);
}
DWORD ExceptionFilter(LPEXCEPTION_POINTERS p)
{
CreateCoreDump(p);
return EXCEPTION_CONTINUE_SEARCH;
}
int _tmain(int argc, _TCHAR* argv[])
{
__try
{
int* p = NULL;
*p = 100;
}
__except(ExceptionFilter(GetExceptionInformation()))
{
}
return 0;
}
Then when you open the dump in windgb, the debugger knows about the exception event. You can use .ecxr to set the current thread and stack at the exception point.
0:000> .ecxr
eax=00000000 ebx=00000000 ecx=6ec4471c edx=00000000 esi=00000001 edi=010c337c
eip=010c108b esp=0038f5e8 ebp=0038f818 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
test!wmain+0x14:
010c108b c70064000000 mov dword ptr [eax],64h ds:002b:00000000=????????
0:000> kc
test!wmain
test!__tmainCRTStartup
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart