HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: aCC generates backtrace when using va_list.
Operating System - HP-UX
1829404
Members
2526
Online
109991
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-28-2002 12:49 PM
01-28-2002 12:49 PM
aCC generates backtrace when using va_list.
I'm porting a large library from gcc 2.95.2 on Solaris to aCC on HP-UX. I have one module from the hundreds I've compiled for which the compiler generates a call stack trace.
The swlist command on our HP-UX 11.0 system shows:
PHSS_24627 1.0 HP aC++ -AA runtime libraries (aCC A.03.33)
PHSS_25170 1.0 HP aC++ Compiler (aCC A.03.31)
The problem appears to be related to va_list.
When compiling the module I'm porting, the
compiler reported a system error. When
compiling a simple sample to demonstrate the
problem, the compiler generated an internal
error.
It should be noted that the internal error was
generated by both
aCC -Ae -c GGtest.c
and
aCC -c GGtest.c
Included below are my simple sample program,
the call stack from the attempted compilation
of that, and the call stack from the module
I'm porting.
Any suggestions of work-arounds, or
observation of error on my part, are greatly
appreciated.
/* GGtest.c.
*
* Try out varargs and see if it will compile with aCC -Ae.
*/
#include
int main (int argc, char** argv)
{
va_list ap;
char *fmt = argv[1];
va_start(ap, fmt);
va_end(ap);
return 0;
}
Here's the call stack from the compile of my
sample program:
( 0) 0x002adcf8 toolError__12ErrorHandlerF11StringTokenRC8Positione + 0x58 [/opt/aCC/lbin/ctcom.pa20]
( 1) 0x00339f54 fe_error + 0x204 [/opt/aCC/lbin/ctcom.pa20]
( 2) 0x008591f8 print_undef + 0x24 [/opt/aCC/lbin/ctcom.pa20]
( 3) 0x0025ef14 scan_symbols + 0x170 [/opt/aCC/lbin/ctcom.pa20]
( 4) 0x00138218 pass1_sllic + 0x34 [/opt/aCC/lbin/ctcom.pa20]
( 5) 0x001448e4 process_sllic_graph + 0xac
[/opt/aCC/lbin/ctcom.pa20]
( 6) 0x00119064 finish_program + 0x94 [/opt/aCC/lbin/ctcom.pa20]
( 7) 0x0010c348 cg_stp + 0xe4 [/opt/aCC/lbin/ctcom.pa20]
( 8) 0x0035c124 be_stp + 0x1c [/opt/aCC/lbin/ctcom.pa20]
( 9) 0x002903e8 ucodeCodeGenTerm__Fv + 0x70 [/opt/aCC/lbin/ctcom.pa20]
(10) 0x00282f60 main + 0x6a8 [/opt/aCC/lbin/ctcom.pa20]
(11) 0xc013e604 _start + 0xc8 [/usr/lib/libc.2]
(12) 0x0010d930 $START$ + 0x1a0 [/opt/aCC/lbin/ctcom.pa20]
Error (internal problem) 7403: Exact position unknown; near
["/usr/include/varargs.h", line 85].
# undefined label - (7403)
The call stack from the compile of the module I'm porting showed a more severe error:
Signal 11
( 0) 0x002a2530 sighandler__FiT1 + 0x148 [/opt/aCC/lbin/ctcom.pa20]
( 1) 0xc01f2de8 _sigreturn [/usr/lib/libc.2]
( 2) 0x001ea744 doReduction3__FiR12ScannerValueP12ScannerValue + 0xb934 [/opt/aCC/lbin/ctcom.pa20]
( 3) 0x001ec7fc yyparse__Fv + 0xc28 [/opt/aCC/lbin/ctcom.pa20]
( 4) 0x00275698 DoCompile__8CompilerFv + 0x20c [/opt/aCC/lbin/ctcom.pa20]
( 5) 0x0010e5ec DoCompile__8CompilerFP6Buffer + 0x34 [/opt/aCC/lbin/ctcom.pa20]
( 6) 0x00118110 DoCompileFile__8CompilerFPc + 0x25c [/opt/aCC/lbin/ctcom.pa20]
( 7) 0x00282ef4 main + 0x63c [/opt/aCC/lbin/ctcom.pa20]
( 8) 0xc013e604 _start + 0xc8 [/usr/lib/libc.2]
( 9) 0x0010d930 $START$ + 0x1a0 [/opt/aCC/lbin/ctcom.pa20]
Error (system problem) 689:
# Compiler received signal 11
The swlist command on our HP-UX 11.0 system shows:
PHSS_24627 1.0 HP aC++ -AA runtime libraries (aCC A.03.33)
PHSS_25170 1.0 HP aC++ Compiler (aCC A.03.31)
The problem appears to be related to va_list.
When compiling the module I'm porting, the
compiler reported a system error. When
compiling a simple sample to demonstrate the
problem, the compiler generated an internal
error.
It should be noted that the internal error was
generated by both
aCC -Ae -c GGtest.c
and
aCC -c GGtest.c
Included below are my simple sample program,
the call stack from the attempted compilation
of that, and the call stack from the module
I'm porting.
Any suggestions of work-arounds, or
observation of error on my part, are greatly
appreciated.
/* GGtest.c.
*
* Try out varargs and see if it will compile with aCC -Ae.
*/
#include
int main (int argc, char** argv)
{
va_list ap;
char *fmt = argv[1];
va_start(ap, fmt);
va_end(ap);
return 0;
}
Here's the call stack from the compile of my
sample program:
( 0) 0x002adcf8 toolError__12ErrorHandlerF11StringTokenRC8Positione + 0x58 [/opt/aCC/lbin/ctcom.pa20]
( 1) 0x00339f54 fe_error + 0x204 [/opt/aCC/lbin/ctcom.pa20]
( 2) 0x008591f8 print_undef + 0x24 [/opt/aCC/lbin/ctcom.pa20]
( 3) 0x0025ef14 scan_symbols + 0x170 [/opt/aCC/lbin/ctcom.pa20]
( 4) 0x00138218 pass1_sllic + 0x34 [/opt/aCC/lbin/ctcom.pa20]
( 5) 0x001448e4 process_sllic_graph + 0xac
[/opt/aCC/lbin/ctcom.pa20]
( 6) 0x00119064 finish_program + 0x94 [/opt/aCC/lbin/ctcom.pa20]
( 7) 0x0010c348 cg_stp + 0xe4 [/opt/aCC/lbin/ctcom.pa20]
( 8) 0x0035c124 be_stp + 0x1c [/opt/aCC/lbin/ctcom.pa20]
( 9) 0x002903e8 ucodeCodeGenTerm__Fv + 0x70 [/opt/aCC/lbin/ctcom.pa20]
(10) 0x00282f60 main + 0x6a8 [/opt/aCC/lbin/ctcom.pa20]
(11) 0xc013e604 _start + 0xc8 [/usr/lib/libc.2]
(12) 0x0010d930 $START$ + 0x1a0 [/opt/aCC/lbin/ctcom.pa20]
Error (internal problem) 7403: Exact position unknown; near
["/usr/include/varargs.h", line 85].
# undefined label - (7403)
The call stack from the compile of the module I'm porting showed a more severe error:
Signal 11
( 0) 0x002a2530 sighandler__FiT1 + 0x148 [/opt/aCC/lbin/ctcom.pa20]
( 1) 0xc01f2de8 _sigreturn [/usr/lib/libc.2]
( 2) 0x001ea744 doReduction3__FiR12ScannerValueP12ScannerValue + 0xb934 [/opt/aCC/lbin/ctcom.pa20]
( 3) 0x001ec7fc yyparse__Fv + 0xc28 [/opt/aCC/lbin/ctcom.pa20]
( 4) 0x00275698 DoCompile__8CompilerFv + 0x20c [/opt/aCC/lbin/ctcom.pa20]
( 5) 0x0010e5ec DoCompile__8CompilerFP6Buffer + 0x34 [/opt/aCC/lbin/ctcom.pa20]
( 6) 0x00118110 DoCompileFile__8CompilerFPc + 0x25c [/opt/aCC/lbin/ctcom.pa20]
( 7) 0x00282ef4 main + 0x63c [/opt/aCC/lbin/ctcom.pa20]
( 8) 0xc013e604 _start + 0xc8 [/usr/lib/libc.2]
( 9) 0x0010d930 $START$ + 0x1a0 [/opt/aCC/lbin/ctcom.pa20]
Error (system problem) 689:
# Compiler received signal 11
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-29-2002 02:45 PM
01-29-2002 02:45 PM
Re: aCC generates backtrace when using va_list.
Perhaps this is specific to your cut-down example,
but I don't think it makes any sense to use va_start(),
va_end(), etc. inside a function with a fixed
argument list such as main(). AFAIK the behavior
is undefined and mayhem will ensue. However, I
do agree that the compiler shouldn't biff on it. gcc,
for example, warns you:
myprog.c: In function `main':
myprog.c:8: `va_start' used in function with fixed args
HP's C compiler doesn't complain, but it doesn't
crash on it either.
If you're trying to process the command line
arguments you can just iterate through argv[]
from 1 through argc-1. Otherwise, perhaps
you could provide an example which has
a variable argument list.
but I don't think it makes any sense to use va_start(),
va_end(), etc. inside a function with a fixed
argument list such as main(). AFAIK the behavior
is undefined and mayhem will ensue. However, I
do agree that the compiler shouldn't biff on it. gcc,
for example, warns you:
myprog.c: In function `main':
myprog.c:8: `va_start' used in function with fixed args
HP's C compiler doesn't complain, but it doesn't
crash on it either.
If you're trying to process the command line
arguments you can just iterate through argv[]
from 1 through argc-1. Otherwise, perhaps
you could provide an example which has
a variable argument list.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-30-2002 06:05 AM
01-30-2002 06:05 AM
Re: aCC generates backtrace when using va_list.
Thanks, Gregory.
I took your advice, and built a new cut-down sample. Unfortunately for me, this sample works. So now I have to go back to the module I'm porting and see if I can find anything else there that looks suspicious, that could be causing the:
Error (system problem) 689:
# Compiler received signal 11
I took your advice, and built a new cut-down sample. Unfortunately for me, this sample works. So now I have to go back to the module I'm porting and see if I can find anything else there that looks suspicious, that could be causing the:
Error (system problem) 689:
# Compiler received signal 11
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-30-2002 08:44 AM
01-30-2002 08:44 AM
Re: aCC generates backtrace when using va_list.
aCC release information can be found here:
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,1743,00.html
Little learning is dangerous!
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP