This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 256054 - Man page is corrupted for access() function on Linux
Summary: Man page is corrupted for access() function on Linux
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 8.1
Hardware: PC Linux
: P3 normal (vote)
Assignee: Vladimir Kvashin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-20 15:24 UTC by Vladimir Kvashin
Modified: 2016-10-31 11:29 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
screenshot (18.00 KB, image/png)
2015-10-20 15:24 UTC, Vladimir Kvashin 		Details
possible fix (1.80 MB, patch)
2015-10-20 15:47 UTC, Vladimir Kvashin 		Details | Diff
Please disregard my previous patch. The correct patch is here. (1.54 KB, patch)
2015-10-20 16:28 UTC, Vladimir Kvashin 		Details | Diff
Show Obsolete (1) Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Kvashin 2015-10-20 15:24:23 UTC 
Created attachment 156845 [details]
screenshot

I used completion for access() function on Linux and got man page corrupted - not totally corrupted, but with strange "?" symbols - see attached screen shot.
Comment 1 Vladimir Kvashin 2015-10-20 15:26:29 UTC 
The stack that creates a man doc is 
"Code Completion"
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.createDocumentationForName(ManDocumentation.java:276)
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.getDocumentationForName(ManDocumentation.java:179)
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.getDocumentation(ManDocumentation.java:158)
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.getDocumentation(ManDocumentation.java:153)
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.getDoc(ManDocumentation.java:135)
	at org.netbeans.modules.cnd.completion.doxygensupport.ManDocumentation.getDocumentation(ManDocumentation.java:116)
	at org.netbeans.modules.cnd.completion.doxygensupport.CompletionDocumentationProviderImpl.createDocumentationImpl(CompletionDocumentationProviderImpl.java:112)
	at org.netbeans.modules.cnd.completion.doxygensupport.CompletionDocumentationProviderImpl.access$000(CompletionDocumentationProviderImpl.java:70)
	at org.netbeans.modules.cnd.completion.doxygensupport.CompletionDocumentationProviderImpl$DocQuery.query(CompletionDocumentationProviderImpl.java:148)
	at org.netbeans.spi.editor.completion.support.AsyncCompletionTask.run(AsyncCompletionTask.java:223)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058)
Comment 2 Vladimir Kvashin 2015-10-20 15:31:03 UTC 
It appends ".UTF-8" to my default locale. If it did not append ".UTF-8", everything would be fine - I checked.

To check this, it isn't necessary to go to debugger - it's enough to do

#MANWIDTH=65 LANG=en_US.UTF-8 man -S2:3 access > /tmp/t; hexdump -c  /tmp/t | head -32

(that's what IDE does right now) - and see strange "342 200 220" in the output
00001b0   k   (   s   )       t   o       b   e       p   e   r 342 200
00001c0 220  \n                               f   o   r   m   e   d   ,

then perform 

#MANWIDTH=65 LANG=en_US man -S2:3 access > /tmp/t; hexdump -c  /tmp/t | head -32

and see that these incorrect symbols disappeared.
Comment 3 Vladimir Kvashin 2015-10-20 15:35:07 UTC 
Adding this postfix was introduced in 
changeset:   207374:844333a22f17
user:        igor_nikiforov <igor_nikiforov@netbeans.org>
date:        Thu Sep 08 15:08:19 2011 +0400
summary:     Bug 185153 "Display man pages on other languages (non-English)" fix.
Comment 4 Vladimir Kvashin 2015-10-20 15:47:57 UTC 
Created attachment 156846 [details]
possible fix

First I thought of just leaving Locale.getDefault() as is. 

But then I understood that the code
...replace(DOT_UTF8, "") + DOT_UTF8
works around some issue. 

So if Locale.getDefault() contains ".UTF8", I left logic as it was.
Comment 5 Vladimir Kvashin 2015-10-20 16:28:18 UTC 
Created attachment 156850 [details]
Please disregard my previous patch. The correct patch is here.