I am getting an exception like
------------[ cut here ]------------
WARNING: at kernel/workqueue.c:806 wq_worker_waking_up+0x74/0x88()
Modules linked in: dc_incdhad1(OF) pvrsrvkm(OF) corelockr(OF) topazkm(OF) vdecdd(OF) imgvideo(OF) tty_hci(F) st_drv(F) wl12xx(F) wlcore(F)
CPU: 1 PID: 277 Comm: kworker/u8:2 Tainted: GF O 3.10.60 #13
Workqueue: pvr_workqueue MISRWrapper [pvrsrvkm]
Stack : 8de85380 80685fd0 8009f7a4 00000326 8068af7c 8077ee40 80715d00 81c08e40
80715cfc 805d7638 80685fd0 800a5bf0 80715d00 00000000 806b193c 8df33bfc
8df33bfc 8de85380 80685fd0 800a0bd4 80688620 00000000 00000151 802eb040
00000000 00000000 00000000 00000000 00000000 00000000 5f727670 6b726f77
75657571 00000065 00000000 00000000 8ea35280 8e848100 c1a5a07c 8df33ba8
...
Call Trace:
[<8005d420>] show_stack+0x64/0x7c
[<800811d4>] warn_slowpath_common+0x78/0xa8
[<8008128c>] warn_slowpath_null+0x18/0x24
[<8009f7a4>] wq_worker_waking_up+0x74/0x88
[<800b35cc>] ttwu_do_activate.constprop.80+0x60/0x80
[<800b58ec>] try_to_wake_up+0x1d4/0x348
[<805dc44c>] __mutex_unlock_slowpath+0x3c/0x54
[<c1a73098>] DisableSGXClocks+0x58/0x108 [pvrsrvkm]
[<c1a72d00>] SysDevicePrePowerState+0x44/0x54 [pvrsrvkm]
---[ end trace f8733685011c8bb9 ]---
Is there any way to read this log, and to reach a definite conlcusion. This log changes in the next boot, but first 5 lines remains same.
Related
Whenever I opens some web link which is hosted on some other system, My chrome crashes (Using 32bit 3GB RAM OS: Windows 8). But it was working fine on other browsers
Following is the trace:
24bdf6a4 55b07bbd e0000008 00000001 00000001 KERNELBASE!RaiseException+0x58
24bdf6c0 55b07b9a 216eb000 24bdf764 5506ffa0 chrome_child!base::`anonymous namespace'::OnNoMemory+0x1d [C:\b\c\b\win_clang\src\base\process\memory_win.cc # 44]
24bdf6cc 5506ffa0 216eb000 54a2d3dc 24bdf6d8 chrome_child!base::TerminateBecauseOutOfMemory+0xa [C:\b\c\b\win_clang\src\base\process\memory_win.cc # 53]
24bdf764 5506facd 24bdf79c 216eb000 0000003e chrome_child!discardable_memory::ClientDiscardableSharedMemoryManager::AllocateLockedDiscardableSharedMemory+0x19e [C:\b\c\b\win_clang\src\components\discardable_memory\client\client_discardable_shared_memory_manager.cc # 373]
24bdf7b0 56403990 24bdf808 216eac00 c40b8000 chrome_child!discardable_memory::ClientDiscardableSharedMemoryManager::AllocateLockedDiscardableMemory+0x207 [C:\b\c\b\win_clang\src\components\discardable_memory\client\client_discardable_shared_memory_manager.cc # 212]
24bdf824 564032f2 24bdf910 24bdfa18 24bdfab0 chrome_child!cc::SoftwareImageDecodeCache::GetExactSizeImageDecode+0x90 [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 605]
24bdf8b4 56404777 24bdf910 24bdfa18 24bdfab0 chrome_child!cc::SoftwareImageDecodeCache::DecodeImageInternal+0x1b2 [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 477]
24bdf94c 56403e13 24bdf9cc 24bdfa18 24bdfab0 chrome_child!cc::SoftwareImageDecodeCache::GetDecodedImageForDrawInternal+0x327 [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 548]
24bdfb9c 564032de 24bdfca0 050ca638 050ca6d0 chrome_child!cc::SoftwareImageDecodeCache::GetScaledImageDecode+0x1c3 [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 728]
24bdfc2c 56402dfe 24bdfca0 050ca638 050ca6d0 chrome_child!cc::SoftwareImageDecodeCache::DecodeImageInternal+0x19e [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 479]
24bdfcd4 564068c0 050ca638 050ca6d0 00000000 chrome_child!cc::SoftwareImageDecodeCache::DecodeImage+0x10e [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 408]
24bdfd48 54d711bc 030a8a64 030a8a48 050ca610 chrome_child!cc::`anonymous namespace'::SoftwareImageDecodeTaskImpl::RunOnWorkerThread+0x70 [C:\b\c\b\win_clang\src\cc\tiles\software_image_decode_cache.cc # 119]
24bdfd98 54add477 00000001 030a8a48 0311111c chrome_child!content::CategorizedWorkerPool::RunTaskInCategoryWithLockAcquired+0x6a [C:\b\c\b\win_clang\src\content\renderer\categorized_worker_pool.cc # 361]
24bdfdb0 54add417 0311111c 030a8a60 031110c8 chrome_child!content::CategorizedWorkerPool::RunTaskWithLockAcquired+0x39 [C:\b\c\b\win_clang\src\content\renderer\categorized_worker_pool.cc # 340]
24bdfdcc 56ae5d06 0311111c 030a8ab0 24bdfe30 chrome_child!content::CategorizedWorkerPool::Run+0x2b [C:\b\c\b\win_clang\src\content\renderer\categorized_worker_pool.cc # 232]
24bdfddc 54add371 031110c8 0000001a 00000000 chrome_child!content::`anonymous namespace'::CategorizedWorkerPoolThread::Run+0x14 [C:\b\c\b\win_clang\src\content\renderer\categorized_worker_pool.cc # 35]
24bdfe30 55af9679 031110c8 000002b8 000002b8 chrome_child!base::SimpleThread::ThreadMain+0x1c1 [C:\b\c\b\win_clang\src\base\threading\simple_thread.cc # 68]
24bdfe54 774aef8c 03133dc0 24bdfea0 7735367a chrome_child!base::`anonymous namespace'::ThreadFunc+0xb9 [C:\b\c\b\win_clang\src\base\threading\platform_thread_win.cc # 92]
24bdfe60 7735367a 03133dc0 405b4b08 00000000 kernel32!BaseThreadInitThunk+0xe
24bdfea0 7735364d 55af95c0 03133dc0 ffffffff ntdll!__RtlUserThreadStart+0x70
24bdfeb8 00000000 55af95c0 03133dc0 00000000 ntdll!_RtlUserThreadStart+0x1b
Any reason, why this error occurs?
I am trying to format a json value on windows which likes:
json::value root;
root["uid"] = "uid";
however, the app crash, when it tries to release sth.
[STACK]
0:019:x86> kb
# ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00 0555f5f8 77248d48 01110000 00000002 0555f638 ntdll_77160000!RtlpNtSetValueKey+0x1b7
01 0555f608 772495f9 0d84b688 011b61a0 01110000 ntdll_77160000!RtlpNtSetValueKey+0x2d58
02 0555f638 771e6168 011b61a0 00000000 00000000 ntdll_77160000!RtlpNtSetValueKey+0x3609
03 0555f694 7347dbeb 01110000 00000000 011b61a8 ntdll_77160000!LdrGetDllPath+0x6d58
04 0555f6a8 7344fe7e 011b61a8 9ab8b012 04f246f0 modwebshell!_free_base+0x1c [d:\th\minkernel\crts\ucrt\src\appcrt\heap\free_base.cpp # 107]
05 (Inline) -------- -------- -------- -------- modwebshell!Json::releaseStringValue+0x6 [\json\json_value.cpp # 174]
06 (Inline) -------- -------- -------- -------- modwebshell!Json::Value::CZString::{dtor}+0x16 [\json\json_value.cpp # 287]
07 0555f7b4 734698c0 734a5018 734a501b 04ee8cc0 modwebshell!Json::Value::resolveReference+0x1ae [json\json_value.cpp # 1091]
08 (Inline) -------- -------- -------- -------- modwebshell!Json::Value::operator[]+0x19 json\json_value.cpp # 1126]
09 0555f870 73465925 04ec03a8 9ab8bf46 7450a320 modwebshell!WebshellManager::ReportAlarm+0x310
==
[WHAT TO RELEASE:]
0:019:x86> dv
block = 0x011b61a8
0:019:x86> dt block
Local var # 0x555f6b0 Type void*
0x011b61a8
Void
==
the part of code is here:
// #param key is not null-terminated.
Value& Value::resolveReference(char const* key, char const* cend)
{
JSON_ASSERT_MESSAGE(
type_ == nullValue || type_ == objectValue,
"in Json::Value::resolveReference(key, end): requires objectValue");
if (type_ == nullValue)
*this = Value(objectValue);
CZString actualKey(
key, static_cast<unsigned>(cend-key), CZString::duplicateOnCopy);
ObjectValues::iterator it = value_.map_->lower_bound(actualKey);
if (it != value_.map_->end() && (*it).first == actualKey)
return (*it).second;
ObjectValues::value_type defaultValue(actualKey, nullSingleton());
it = value_.map_->insert(it, defaultValue);
Value& value = (*it).second;
return value;
}
anyone could give some hint? thanks!
Well, after some investigation, it is because i broke the heap from some other place.
From ELF Documentation:
SHT_STRTAB
The section holds a string table. An object file may have multiple string table sections. See ‘‘String Table’’ below for details.
(Note: I didn't notice any information regarding multiple string table sections in ‘‘String Table’’ paragraph)
Does multiple string table sections mean string table for the section headers and string table for the object file itself?
There is no mention in the documentation regarding how to read a string if there are multiple string table for the object itself (.strtab).
Any clarification about the subject appreciated.
The manpage only has a overview/summary of (some parts of) the ELF file format, you might want to look at the System V ABI spec.
Explanation
Linking view
An ELF file has multiple string tables. Usually you have 3-4 string tables:
One string table (usually called .shstrtab) is used for section names. All section names (in the section header table) are taken from a single string table. This string table is identified by its index in the section header table: the index of the section name string table is indicated in the ELF header (e_shstrndx).
Another string table (usually called .strtab) is used for the full symbol table (.symtab). The same string table is used by the .dynamic section.
Another string table (usually called .dynstr) is used for the minirmal symbol table (.dynsym).
Another string table is used for
For a given symbol table section, the section used as string table is indicated in the sh_link field of the section header table (see Fig 4-12 of the system V ABI spec).
Execution view
For the execution view (the program header table), the address of the string table used for the symbol table (DT_SYMTAB) is given in the DT_STRTAB entry of the dynamic section.
Example
Linking view
This is a hello world program (shown with readelf -a).
.shtrtab
The ELF header:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4003c0
Start of program headers: 64 (bytes into file)
Start of section headers: 4624 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 30
Section header string table index: 27
tells us that the section names are in section 27. Conveniently enough this is .shtrtab:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[...]
[27] .shstrtab STRTAB 0000000000000000 000008e0
0000000000000108 0000000000000000 0 0 1
.dynstr
For .dynsym we have:
[ 5] .dynsym DYNSYM 0000000000400280 00000280
0000000000000048 0000000000000018 A 6 1 8
^
HERE
Its names are taken from section 6 which is .dynstr:
[ 6] .dynstr STRTAB 00000000004002c8 000002c8
0000000000000038 0000000000000000 A 0 0 1
This string table is used by other sections as well:
[ 8] .gnu.version_r VERNEED 0000000000400308 00000308
0000000000000020 0000000000000000 A 6 1 8
[21] .dynamic DYNAMIC 0000000000600698 00000698
00000000000001d0 0000000000000010 WA 6 0 8
.strtab
For .symtab:
[28] .symtab SYMTAB 0000000000000000 000009e8
0000000000000600 0000000000000018 29 45 8
^
HERE
the names are taken from section 29 which happens to be .strtab:
[29] .strtab STRTAB 0000000000000000 00000fe8
0000000000000224 0000000000000000 0 0 1
Execution view
Dynamic section at offset 0x698 contains 24 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x400370
0x000000000000000d (FINI) 0x400544
0x0000000000000019 (INIT_ARRAY) 0x600680
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x600688
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x400260
0x0000000000000005 (STRTAB) 0x4002c8 <= HERE
0x0000000000000006 (SYMTAB) 0x400280
0x000000000000000a (STRSZ) 56 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x600870
0x0000000000000002 (PLTRELSZ) 48 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x400340
0x0000000000000007 (RELA) 0x400328
0x0000000000000008 (RELASZ) 24 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x400308
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x400300
0x0000000000000000 (NULL) 0x0
The string table for dynamic linking is located at 0x4002c8 in the program memory.
Note: this is .dynstr.
I can't seem to get past this hurdle. Mapserver isn't throwing any errors...but it isn't returning anything either...I suspect my logical expression (... in the absence of any errors...I really have little clue what is going down here).
Ideally, I'd like to filter by my shapefile using these two columns: '[YODA] (text)' AND '[ZOOM] (Integer)'.
Currently my code reads as:
LAYER
# Zoom Level 11-16
TYPE ANNOTATION
STATUS ON
GROUP "yoda"
DATA "yoda_graphics"
NAME "yoda_awesome"
# # Visible in map from zoom level 11 onwards
MAXSCALEDENOM 325008
MINSCALEDENOM 5078
LABELITEM "label"
CLASS
# Yoda Head
EXPRESSION (('[YODA]' ~* '/^I/') AND ([Zoom]>8)) ## where things are suspect...
# yoda shell symbol w/ label
STYLE
SYMBOL 'yoda_red_top_shell'
#COLOR 255 255 255
#COLOR 218 218 203
COLOR 184 184 156
SIZE 16
END
STYLE
SYMBOL 'yoda_red_top_shell'
#COLOR 225 104 104
#COLOR 204 184 181
COLOR 214 214 169
SIZE 15
END
STYLE
SYMBOL 'yoda_blue_shell'
#COLOR 80 101 123
#COLOR 183 192 221
COLOR 241 241 226
SIZE 15
END
LABEL
TYPE truetype
FONT "deja-bold"
SIZE 5
#COLOR 255 255 255
COLOR 184 184 156
PARTIALS FALSE
WRAP " "
ALIGN center
POSITION CC
ANGLE 0
END # end label
END #end class
END # layer
You shouldn't surround your regular expression with slashes when using an explicit regular expression operator.
This is correct:
CLASSITEM "Yoda"
CLASS
EXPRESSION /^I/
In your case, use:
EXPRESSION (('[YODA]' ~* '^I') AND ([Zoom]>8))
I'm trying to train tesseract (adding a new, digit only font) as per the instructions found here: http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3
What I've done:
Created a PDF with sample text, converted to tif, ran tesseract num.dot.exp0.tif num.dot.exp0 batch.nochop makebox digits. Then edited the generated box file, correcting wrong detections
Ran tesseract on training mode: tesseract num.dot.exp0.tif num.dot.exp0 nobatch box.train and extracted the unicharset with unicharset_extractor num.dot.exp0.box
Created the font_properties file: echo "num.dot.exp0 0 0 0 0 0" > font_properties
Everything was OK so far, the .box and unicharset files are correct, num.dot.exp0.tr was generated.
Then I ran shapeclustering -F font_properties -U unicharset num.dot.exp0.tr and got the following error:
Reading num.dot.exp0.tr ...
*** glibc detected *** shapeclustering: double free or corruption (!prev): 0x098c52e0 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0x82eee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0x77d51f]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdaPv+0x1b)[0x77d57b]
shapeclustering(_ZN13GenericVectorIiE5clearEv+0x8b)[0x8050949]
shapeclustering(_ZN13GenericVectorIiED1Ev+0x2b)[0x805056b]
/usr/lib/libtesseract.so.3(_ZN9tesseract17TrainingSampleSet14SetupFontIdMapEv+0x137)[0x488699]
/usr/lib/libtesseract.so.3(_ZN9tesseract17TrainingSampleSet22OrganizeByFontAndClassEv+0x22)[0x48823c]
/usr/lib/libtesseract.so.3(_ZN9tesseract13MasterTrainer24ReplaceFragmentedSamplesEv+0x1d7)[0x477ebd]
/usr/lib/libtesseract.so.3(_ZN9tesseract13MasterTrainer15PostLoadCleanupEv+0x47)[0x47587b]
shapeclustering[0x804e2b9]
shapeclustering(main+0x5f)[0x804cb13]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7d24d3]
shapeclustering[0x804ca21]
(...)
00cba000-00cc1000 rw-p 0039c000 08:01 4465015 /usr/lib/libtesseract.so.3.0.2
00cc1000-00d5c000 rw-p 00000000 00:00 0
00ef8000-00f22000 r-xp 00000000 08:01 4211867 /lib/i386-linux-gnu/libm-2.15.so
00f22000-00f23000 r--p 00029000 08:01 4211867 /lib/i386-linux-gnu/libm-2.15.so
00f23000-00f24000 rw-p 0002a000 08:01 4211867 /lib/i386-linux-gnu/libm-2.15.so
08048000-08056000 r-xp 00000000 08:01 4464615 /usr/bin/shapeclustering
08056000-08057000 r--p 0000d000 08:01 4464615 /usr/bin/shapeclustering
08057000-08058000 rw-p 0000e000 08:01 4464615 /usr/bin/shapeclustering
093c5000-094cf000 rw-p 00000000 00:00 0 [heap]
b779a000-b77a0000 rw-p 00000000 00:00 0
b77b6000-b77ba000 rw-p 00000000 00:00 0
bfb6c000-bfb8d000 rw-p 00000000 00:00 0 [stack]
Aborted (core dumped)
Then an empty shapetable is created.
Have I done something wrong? Any clues as to why this is happening?
I'm using tesseract 3.02
I managed to find out the problem. I should have used echo "dot 0 0 0 0 0" > font_properties instead of echo "num.dot.exp0 0 0 0 0 0" > font_properties
shapeclustering worked properly after that. It needs the real font name on font_properties, not the complete name ("dot", in my case).
I was getting same issue but found solution by verifying font name in font_properties file should be same as in eng.Imagefile.tr.
echo "NewFont 0 0 0 0 0" > font_properties
shapeclustering -F font_properties -U unicharset eng.Imagefile.tr
mftraining -F font_properties -U unicharset -O eng.unicharset eng.Imagefile.tr