bugDDD - Bugs: bug #41485, SourceView.C:8724: assertion...

 
 

bug #41485: SourceView.C:8724: assertion `*proc_id == *id' failed

Submitter:  Peeter Joot <peeterjoot>
Submitted:  Thu 06 Feb 2014 07:21:48 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 28 Dec 2022 07:05:58 PM UTC, comment #3: 

internally DDD uses C.ISO-8859-1 independent from the LANG setting

Stefan Eickeler <eickeler>
Group administrator
Tue 17 May 2016 12:49:40 PM UTC, comment #2: 

It turns out the the work around is not working 100% of the time, but its better then before.  If anyone was figured out how to fix this please add a comment saying what you did to fix it.

John T. Kerich <jkerich>
Mon 09 May 2016 09:34:15 PM UTC, comment #1: 

We just updated to RHEL 7.2 and are using 3.3.12 ddd and found that this bug is happening to us too. However; if we Edit->Preferences, Select Tab Source, and select Show Position as Text Characters vs. the default Glyphs the core stops.  Also, if LANG unset or set to C it works with Select Tab Source as Glyphs. But we need to set LANG=en_US.UTF-8 for Sybase to work.

We noticed that some adobe symbol fonts are missing. Is there is some X11 font package required?  The SA are only installing packages as needed vs. installing everything.  We never had this problem on the old RHEL 5 boxes.

John T. Kerich <jkerich>
Thu 06 Feb 2014 07:21:48 PM UTC, original submission:  

SourceView.C: In function `static void SourceView::UpdateGlyphsWorkProc(void*, XtIntervalId*)':
SourceView.C:8724: assertion `*proc_id == *id' failed
Aborted (core dumped)

Core was generated by `ddd -d /vbs/common/osse/core/src -d /vbs/common/osse/core/inc -d /vbs/engn/sqe'.
Program terminated with signal 6, Aborted.
#0  0x00007fd2f2280b55 in raise () from /lib64/libc.so.6
(gdb) where
#0  0x00007fd2f2280b55 in raise () from /lib64/libc.so.6
#1  0x00007fd2f2282131 in abort () from /lib64/libc.so.6
#2  0x0000000000428fdd in ddd_assert_fail (assertion=0x622e52 "*proc_id == *id", file=<value optimized out>, line=<value optimized out>,
    function=0x623ce0 "static void SourceView::UpdateGlyphsWorkProc(void*, XtIntervalId*)") at assert.C:38
#3  0x00000000005a53d1 in SourceView::UpdateGlyphsWorkProc (client_data=0x8aa218, id=<value optimized out>) at SourceView.C:8724
#4  0x0000000000435b53 in MyTimerProc (client_data=0xb89cc0) at TimeOut.C:114
#5  0x00007fd2f3d6374f in ?? () from /usr/lib64/libXt.so.6
#6  0x00007fd2f3d638a9 in XtAppNextEvent () from /usr/lib64/libXt.so.6
#7  0x000000000041441a in process_next_event () at ddd.C:3221
#8  0x00000000004d685d in ddd_main_loop () at mainloop.C:120
#9  0x000000000042673b in main (argc=<value optimized out>, argv=<value optimized out>) at ddd.C:3175

Unfortunately, this assertion doesn't dump the values that it is failing, and the build is optimized, and unavailable from the core:

(gdb) frame 3
#3  0x00000000005a53d1 in SourceView::UpdateGlyphsWorkProc (client_data=0x8aa218, id=<value optimized out>) at SourceView.C:8724
8724            assert(*proc_id == *id);
(gdb) p id
$1 = <value optimized out>
(gdb) p proc_id
$2 = <value optimized out>

Not sure if the value is available from the regs, since it looks like %rdi gets clobbered by the assert call:

Dump of assembler code for function SourceView::UpdateGlyphsWorkProc(XtPointer, XtIntervalId*):
   0x00000000005a5390 <+0>:     mov    %rbx,-0x20(%rsp)
   0x00000000005a5395 <+5>:     mov    %rbp,-0x18(%rsp)
   0x00000000005a539a <+10>:    mov    %rdi,%rbx
   0x00000000005a539d <+13>:    mov    %r12,-0x10(%rsp)
   0x00000000005a53a2 <+18>:    mov    %r13,-0x8(%rsp)
   0x00000000005a53a7 <+23>:    sub    $0x28,%rsp
   0x00000000005a53ab <+27>:    test   %rdi,%rdi
   0x00000000005a53ae <+30>:    je     0x5a53e0 <SourceView::UpdateGlyphsWorkProc(XtPointer, XtIntervalId*)+80>
   0x00000000005a53b0 <+32>:    mov    (%rsi),%rax
   0x00000000005a53b3 <+35>:    cmp    %rax,(%rdi)
   0x00000000005a53b6 <+38>:    je     0x5a53d1 <SourceView::UpdateGlyphsWorkProc(XtPointer, XtIntervalId*)+65>
   0x00000000005a53b8 <+40>:    mov    $0x623ce0,%ecx
   0x00000000005a53bd <+45>:    mov    $0x2214,%edx
   0x00000000005a53c2 <+50>:    mov    $0x622aec,%esi
   0x00000000005a53c7 <+55>:    mov    $0x622e52,%edi
   0x00000000005a53cc <+60>:    callq  0x428eb0 <ddd_assert_fail(char const*, char const*, unsigned int, char const*)>
=> 0x00000000005a53d1 <+65>:    movq   $0x0,(%rdi)
   0x00000000005a53d8 <+72>:    nopl   0x0(%rax,%rax,1)
   0x00000000005a53e0 <+80>:    mov    0x3048e9(%rip),%rdi        # 0x8a9cd0 <_ZN10SourceView13source_text_wE>

Here's what was in the regs for this frame:

(gdb) info registers
rax            0x0      0
rbx            0x8aa218 9085464
rcx            0xffffffffffffffff       -1
rdx            0x6      6
rsi            0x2df0d7 3010775
rdi            0x2df0d7 3010775
rbp            0x7fff349f8ea8   0x7fff349f8ea8
rsp            0x7fff349f8e30   0x7fff349f8e30
r8             0xffffff00       4294967040
r9             0x7fd2f25c0e60   140543985978976
r10            0x8      8
r11            0x246    582
r12            0x8cc7e0 9226208
r13            0x0      0
r14            0x0      0
r15            0x7fff349f8f20   140734076260128
rip            0x5a53d1 0x5a53d1 <SourceView::UpdateGlyphsWorkProc(XtPointer, XtIntervalId*)+65>
eflags         0x246    [ PF ZF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0


Peeter Joot <peeterjoot>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eickeler (Updated the item)
  • -email is unavailable- added by jkerich (Posted a comment)
  • -email is unavailable- added by peeterjoot (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-12-28 eickeler StatusNone Fixed
    2022-12-28 eickeler Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code