How webkit3 resolve its primary font on Linux?
(Got a segmentation fault in libwebkitgtk-3.0. Anybody has seen similar problem? Is there a way to work-around it? How to debug or fix it with minimal change to the system?)
The gdb prints:
Program received signal SIGSEGV, Segmentation fault.
0x74a1bc87 in WebCore::RenderStyle::fontMetrics() const () from /lib/libwebkitgtk-3.0.so.0
The gdb backtrace after installed debuginfo:
(gdb) bt
#0 primarySimpleFontData (...) at Source/WebCore/platform/graphics/FontGlyphs.h:123
#1 primaryFont (...) at Source/WebCore/platform/graphics/Font.h:326
#2 fontMetrics (...) at Source/WebCore/platform/graphics/Font.h:143
#3 WebCore::RenderStyle::fontMetrics
(...) at Source/WebCore/rendering/style/RenderStyle.cpp:1335
#4 0x74a1bea3 in WebCore::RenderStyle::computedLineHeight
(...) at Source/WebCore/rendering/style/RenderStyle.cpp:1376
#5 0x7488ef06 in WebCore::RenderBlock::lineHeight
(...) at Source/WebCore/rendering/RenderBlock.cpp:6651
Steps lead to this:
Install pyjs.org following its readme file, set the virtualenv to pyjsroot/mypy.
Install webkitgtk3 and pygobject3.
Source an environment setting file to set PATHONPATH to pyjsroot:/lib/python2.7/site-packages
Run in pyjsroot "mypy/bin/python examples/helloworld/Hello.py"
Edit: Added the gdb backtrace. The backtrace tells me webkit could not resolve "primary font" properly. Change title from old "segmentation in libwebkitgtk-3.0 on fedora 20 when running pyjs" to reflect this.
Changed to Frdora 21, the segmentation fault is gone, but it does not show characters properly. Installed the following packages then everything is ok.
xorg-x11-fonts-ISO8859-1-100dpi
gnu-free-fonts-common
gnu-free-mono-fonts
gnu-free-sans-fonts
gnu-free-serif-fonts
Not sure the xorg-x11-fonts-ISO8859-1-100dpi is needed or not, but it does bring in dependencies. Among the gnu-free-*, the -common is needed, and one of the other three is needed. Without installing all the other three, the characters will just be show in whatever font is installed.
The above fonts should also solve the problem on Fedora 20.
Related
When running srb init in a Rails app I get the following:
Generating /tmp/d20220723-3779490-paqj5l/reflection.rbi with 6784 modules and 142 aliases
Printing your code's symbol table into /tmp/d20220723-3779490-paqj5l/from-source.json
/home/allan/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/sorbet-0.5.10206/lib/hidden-definition-finder.rb:123:in `write_constants': Your source can't be read by Sorbet. (RuntimeError)
You can try `find . -type f | xargs -L 1 -t bundle exec srb tc --no-config --isolate-error-code 1000` and hopefully the last file it is processing before it dies is the culprit.
If not, maybe the errors in this file will help: /tmp/d20220723-3779490-paqj5l/from-source.json.err
When I check that error file I find this:
Exception::raise(): Unimplemented Parser Node: EmptyElse
Is there a workaround to get past this error?
Anytime you see Exception::raise in a Sorbet error message, it means there was a bug in Sorbet. You can report Sorbet bugs at https://github.com/sorbet/sorbet/issues
I have created a fix for this bug here: https://github.com/sorbet/sorbet/pull/6161
It will require upgrading Sorbet before you can take advantage of the fix. If you can't wait for that, you will have to hunt down the file in your codebase that uses Ruby's new case ... in syntax for pattern matching with an empty else keyword, and either delete the else keyword or change it to mention else nil instead.
Sorry for the inconvenience.
In the future, please use https://github.com/sorbet/sorbet/issues to report all issues—I only happened to see this by accident today, but I normally do not monitor StackOverflow for bug reports.
I am trying to use google breakpad, but I am facing a strange issue.
i am working in linux. I have my own library, my_lib.so, which I process with dump_syms and generates this symbol :
$ dump_syms my_lib.so|head -2
MODULE Linux mips 3BB485681467218D36EB2FF02287096C0 my_lib.so
INFO CODE_ID 6885B43B67148D2136EB2FF02287096C
I create the symbols directory with the appropiate subdirectories. I then generate a minidump for the program that uses a stripped version of my_lib.so, but when I try to process it with minidump_stackwalk:
0x77dce000 - 0x77e23fff my_lib.so ??? (WARNING: No symbols, my_lib.so, AC40136B433E5A68F66CCE8C2C2E6C250)
It is seaching for a differente ID, AC40136B433E5A68F66CCE8C2C2E6C250, so it does not find the symbols. Why the mismatch?
Knowing that it searches for AC40136B433E5A68F66CCE8C2C2E6C250 I manually changed the tree directory in symbols, to match that one, just to test. I also changed the id inside the my_lib.so.sym file, and then minidump_stalkwalk does not complain about not finding the symbols, but still I can't see the stack trace.
Any ideas about this mismatch?
by the way, if I run readelf -n over the original library and the stripped one, I get the same GNU BUILD ID.
I am attached to a running proces using dbx on AIX. There is a bug in the program, the offset in the opcode below is 0x9b8, but should be 0xbe8:
(dbx) listi 0x100001b14
0x100001b14 (..........+0x34) e88109b8 ld r4,0x9b8(r1)
I am able to fix that using the command below:
(dbx) assign 0x100001b14 = 0xe8810be8
but that affects only the running process and its memory. How can I change the on disk binary? I am not able to locate the pattern e88109b8 in the binary file,
otherwise I would use e.g. dd utility to patch it.
Best regards,
Pavel Filipensky
I have next workflow:
1) Build dll and pdb files.
2) Share dll to cutomer
3) Analize memory dump from customer.
When I run !analyze -v in WinDbg I got (below part of output)
....
MANAGED_STACK_COMMAND: _EFN_StackTrace
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
// some callstack here
MODULE_NAME: RTPLogic
IMAGE_NAME: RTPLogic.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 58a43706
STACK_COMMAND: ~541s; .ecxr ; kb
FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+1da
Looks like we have wrong debug symbol for RTPLogic.dll.
I download ChkMatch tool.
I get pdb path from windbg
0:541> !lmi RTPlogic.dll
Loaded Module Info: [rtplogic.dll]
Module: RTPLogic
.....
Age: 1, Pdb: D:\Work\path_to_original_pdb\RTPLogic.pdb
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from image header.
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
I have logs related to this dump and I see that my changes appears in logs. So customer not forgotten to install my DLL before get the memdump.
I run ChkMatch
PS D:\tools> .\ChkMatch.exe -c "D:\Work\path_to_dll\RTPLogic.dll" "C:\Progra
mData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb"
.....
Result: Matched
How it possible that I got wrong debug symbols in such situation?
The symbols for RTPLogic.dll!CSRTPStack::Finalize are correct, but other symbols that are required to reconstruct the call stack are incorrect. It's likely that you have some operating system methods on the call stack and the symbols for ntdll or similar are missing.
Since with ChkMatch, you're only checking one single PDB file, the result of ChkMatch is as reliable and correct (for one PDB) as that of WinDbg (for many PDBs) and they do not contradict each other.
Your sympath probably contains only a local path to your own DLLs and does not contain any information about Microsoft's symbol server. In the output of .sympath (which you did not post), I expect to see something like
0:000> .sympath
D:\Work\path_to_dll
You should include Microsoft symbols as well, as described in How to set up symbols in WinDbg. To fix the problem, use the following commands:
.symfix+ c:\symbols
.reload /f
The output of .sympath should now look like
0:000> .sympath
D:\Work\path_to_dll;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
This should help WinDbg in reconstructing the complete call stack, resolve OS methods of ntdll and others and thus get rid of the "wrong symbols" message.
I hate Xcode 4! It crashes all the time and finally it gives me an error in CABase.h file which is an library header file that I am not allowed to modify..
I don't even know how this file is broken.
How to fix this problem? It complains like
"Expected *before*
Expected '=',',',';','asm' or '_attribute_' before 'extern'
Also, how can I completely remove Xcode on my Mac and re-install?
You probably just have a simple error, perhaps in a header which is included prior to CABase.h. Use a "divide and conquer" strategy to locate it.
To answer your last question:
$ sudo /Developer/Library/uninstall-devtools –mode=all
This happened to me just because I had the letter 's' at the beginning of one of my implementation files. I must have missed the cmd key when cmd+s for saving the file. Luckily, another compile error discovered this and removing the 's' fixed both errors.
For example,
s//
// GraphingViewController.m