Getting rid of Persistent SIGABRT error - objective-c

I keep getting the SIGABRT error with my app. I've tried re-downloading my entire developer profile certificates and provisioning certs etc and still no change. I've also played with changing architectures. The activity log for my project when it crashes is below - any one know what's causing it?
[CODE]GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Fri Sep 16 06:56:50 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys001
sharedlibrary apply-load-rules all
target remote-mobile /tmp/.XcodeGDBRemote-1268-71
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
[Switching to process 7171 thread 0x1c03]
[Switching to process 7171 thread 0x1c03]
Couldn't register sh.heather.reactionfree with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.(gdb) [/CODE]

I've had this problem a few times. I'm not sure but it seems to occur for me when I continually build and run without stopping the previous build in the simulator. (I try to always press the stop button now)
Things to try
Sometimes this is fixed by just quitting the simulator and Xcode.
Sometimes I've had to do a full system restart.
So they may get you back on your feet quickly but I would also enjoy hearing the reason/fix from someone who knows more.

you must be having memory management issues,. just clean build it and then press analyze for any issues/ leaks and dead memory management problems... once all are cleared then your program functions as per your coding.

Related

Terminal process get killed with code ELIFECYCLE errno: 137 when VS Code is open. Quitting VS Code resolves the issue?

I've only recently in the last two days begun encountering this issue.
When I attempt to build my Angular project, It's getting to this one point and failing with errors below.
The only way I can get it to run is to quit VS code and rerun the exact same command and it builds without issue.
Any ideas what may be causing this?
137 is 128 + 9. In some situations—and I'm guessing that this is one of them—this indicates that the process died with a signal 9. Signal 9 is, on macOS (and multiple other OSes), SIGKILL. This signal is sent by the "out of memory" killer.
This also explains why exiting VSCode fixes things: VSCode is a memory hog. Exiting it returns the memory to the system.
To fix this more permanently, either reduce the memory needs of your build and/or of VSCode, or add more memory to your system.
See also What killed my process and why?

ilink64 Error: Fatal: Malloc of 65536 bytes failed

I'm transfering project for C++ Builder 6 on Embarcadero RAD Studio 10.4 and change platform with x86 on x64. My project include five *.dll and two *.exe files.
I success transfer four *.dll on x64 platform, but fifth *.dll report about error. When *.dll - file make, I get message about error: "Out of memory". I visited url:
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Handling_Out_of_Memory_Errors
and found out, that in my happening overflow three heap:
Code Heap Size
Dwarf str Heap Size
Info Heap Size
Little by little I enlarged size all heaps. But, soon I reached limitation: "[ilink64 Error] Fatal: Malloc of 65536 bytes failed in ........\bins\Win64\Debug\my_dll.ildw_str, line 6"
About this signaling Dwarf str Heap Size.
I visited url:
https://stackoverflow.com/a/37537734/9494441
and maked all tips.
I tryed:
Setted Large Address Aware flag with the lamarker tool
Replace ilink32.exe and ilink64.exe program RAD Studio with version 10.4 on version 10.2.3
Incremental linker disabled/enabled
Manually removing all files in /debug
all rebuild
add files to the antivirus exclusions ilink32.exe and ilink64.exe
Me didn't help nothing. How fix this problem? Thanks!
This is happening only in debug, right?
4 options you have:
Reduce the memory of the sections you are allocating more than you project needs. Not to allocate more memory than neede in the other sections.
Reduce all the symbols your modules are expose to. I've been told that the linker does not detect duplicates and same symbols get included again and again making the things worse. If the project is old and have a poor include policy you might have something to work on there
Compile all in release and enable debug info only on the modules you are going to debug.
Try to use 10.3.1 where C++ win64 was not yet C++17. In 10.3.2 Win64 was upgraded to C++17 making the linker problem more likely to happen.

Is there an updated disk image binary for the x86 architecture for running gem5 in full system mode?

I am currently using the linux-x86.img which I downloaded from the documentation page for gem5 (http://www.m5sim.org/Download), but since I was not able to compile the fscanf and fopen commands on this image I was wondering if there is a more recent image which I could download and use instead.
The error message throw when trying to compile the lines with fopen and fscanf are
./obj/edgelist.o: In function loadEdgeArray': edgelist.c:(.text+0x148): undefined reference to __isoc99_fscanf'
./obj/edgelist.o: In function loadEdgeArrayInfo': edgelist.c:(.text+0x20c): undefined reference to __isoc99_fscanf'
collect2: ld returned 1 exit status
make: *** [test] Error 1
This error is thrown when trying to compile from both from qemu as well as gem5.
Here's one setup that generates such an image with Buildroot. I'm a fan of Buildroot because it builds everything from source. I don't understand how fscanf and fopen could fail in that image, but I have tested them in the above setup and they work fine.
Boot used to work in the past, but gem5 X86 full system boot has been broken for likely easy to fix reasons for a few months now as of March 2020 on the gem5 side, although there are efforts in place to fix it, and so likely it will work again soon: https://www.gem5.org/project/2020/03/09/boot-tests.html
Other alternatives include:
https://gem5art.readthedocs.io/en/latest/ which Jason has been pushing and uses Packer to generate disk images
You can also extract working disk images from Docker: https://hub.docker.com/_/ubuntu This requires exporting them to a file to give to gem5.
It is also worth noting that when the gem5.org website migrated from the old Wiki to the new static website setup in Q1 2020, we lost the ability of doing directory listing under http://dist.gem5.org/dist/current/arm/ for some reason, and so devs were forced to list them one by one on the static website... https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
I am not sure why the error is no longer occurring for me, but documenting the steps I went through which might have fixed something. I reinstalled Ubuntu18.04 therefore had to rebuild gem5 and I used the parsec image (http://www.cs.utexas.edu/~parsec_m5/x86root-parsec.img.bz2) referenced in this answer Booting gem5 X86 Ubuntu Full System Simulation

I am getting this error message while trying to use Testng in Eclipse?

I am getting the error message such as stack overflow, heap memory error and similar messages after trying to use TestNG. And after installing TestNg the Eclipse feels heavy and became very slow to respond. and throwing this error message.
An error of such kind Stackoverflow and heap memory error occurs because of physical lack of resources such as lower Ram or slower processor. So the only solution to this was to allocate more memory to eclipse IDE. you can allocate more memory to eclipse by finding the eclipse.ini file in your directory where you have installed it. After finding the file, the file should be in notepad. open the file in notepad and edit the memory allocated. there are two things you need to change. Xms and XMX, which is minimum and max memory. I made mine from 256m to 512m for XMS and from 1024m to 2048M. But make sure you allocate only the memory which is spare. otherwise your PC might crash. Hope this helps.

How to determine whether a hardware or a software watchdog is implemented on the machine?

I have an embedded computer I am trying to develop on and I wanted to know if the watchdog it has is a software watchdog or if it is a hardware watchdog.
First I checked and I saw that /dev/watchdog is present inside /dev. But I did not see a watchdog process when I issued ps. So I installed a watchdog daemon (or driver?) and verified that a watchdog is running, again I used ps.
My problem now is I have no idea whether this is a hardware or software watchdog... there is a .conf file and also a process called /usr/sbin/watchdog owned by root. In case that info helps.
TIA!
Niko
The dmidecode does NOT show the watchdog information on this machine, whereas it does show watchdog present info on my peer's laptop:
On the other hand on my computer the /dev folder is NOT showing the watchdog entry nor does lsmod|grep softdog show anything.
From here: http://www.sat.dundee.ac.uk/psc/watchdog/watchdog-testing.html
Checking for the Watchdog Hardware
If you have successfully loaded the watchdog hardware's driver module (or the 'softdog' > emulator) then you should see the entry in /dev corresponding to this. For example:
ls -l /dev/watch*
crw------- 1 root root 10, 130 May 13 16:27 /dev/watchdog
I need to know which module do I need to load for hardware watchdog and for that I need to know what module does my hardware watchdog require!
One board I have is: CAPA830 with Ubuntu 12.04 on it
and other is:
3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
dmesg on the second machine shows:
NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
If you are talking about Linux's software watchdog then softdog module should be loaded, which you can verify with
$lsmod|grep softdog
softdog 13319 0
Only one watchdog could be present per system. That could be either a software watchdog or a hardware watchdog. Generally when a watchdog(software/hardware) is inserted, the kernel creates a device node as /dev/watchdog. You can check if the file is present or not. If yes, watchdog is active on your machine, else not.
Now, the /usr/bin/watchdog that your were referring to is a watchdog daemon. It runs in the background and continuously reports the system status to the watchdog(either implemented as hardware/software).
For more info on the daemon, please refer to the man page of watchdog man watchdog.
To check if it is a hardware/software watchdog, just do :
$ lmsmod | grep softdog
If you get an output, your system is running a software watchdog, else a hardware watchdog is implanted into the system. This check is to be done, provided, that you have a node named /dev/watchdog present.
Hope this helps.