将 Unix ada 应用程序移植到 Linux：程序开始前出现段错误
我是一名实习生，负责将测试应用程序从 Solaris 移植到 Red Hat。 该应用程序是用 Ada 编写的。 它在 Unix 端工作得很好。 我在linux端编译了它，但现在它给了我一个段错误。 我运行调试器来查看错误所在，并得到以下信息：
警告：在非 Ada 任务中，选择 Ada 任务。 => 运行时任务结构尚未初始化。 <非 Ada 任务> 线程 ID 0b7fe46c0 处理接收到的信号“分段错误”[11] 任务 #1 在 _dl_allocate_tls 中停止 at 0870b71b: mov edx, [edi] ;edx := [edi]
此段错误发生在进行任何调用或初始化任何内容之前。 有人告诉我 ada 中的“任务”在程序的其余部分之前启动，问题可能出在正在运行的任务上。
但这是最关键的。 该程序只是生成一些代码供另一个程序使用。 OTHER 程序在 Linux 下编译时给出了相同类型的段错误和相同类型的错误消息。 这让我相信我可以用一些小调整来解决所有这些问题，但我对 Unix、Linux 和 Ada 没有足够的了解，无法自己解决这个问题。
I am an intern who was offered the task of porting a test application from Solaris to Red Hat. The application is written in Ada. It works just fine on the Unix side. I compiled it on the linux side, but now it is giving me a seg fault. I ran the debugger to see where the fault was and got this:
Warning: In non-Ada task, selecting an Ada task.
=> runtime tasking structures have not yet been initialized.
<non-Ada task> with thread id 0b7fe46c0
process received signal "Segmentation fault" [11]
task #1 stopped in _dl_allocate_tls
at 0870b71b: mov edx, [edi] ;edx := [edi]
This seg fault happens before any calls are made or anything is initialized. I have been told that 'tasks' in ada get started before the rest of the program, and the problem could be with a task that is running.
But here is the kicker. This program just generates some code for another program to use. The OTHER program, when compiled under linux gives me the same kind of seg fault with the same kind of error message. This leads me to believe there might be some little tweak I can use to fix all of this, but I just don't have enough knowledge about Unix, Linux, and Ada to figure this one out all by myself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这完全是在黑暗中进行的，但是如果任务试图在堆栈上分配太多本地内存，则可能会在启动时让任务像这样崩溃。 您的主程序可以安全地使用系统堆栈，但任务必须在启动时从动态内存中分配其堆栈，因此通常您的运行时具有默认的任务堆栈大小。 如果您的任务尝试分配一个大数组，它很容易超出该限制。 我以前也遇到过这种情况。
有多种方法可以解决这个问题。 一种方法是将所有任务本地数据移至包全局区域。 另一种是动态分配。
如果您可以计算出多少内存就足够了，那么您还有更多选择。 您可以将任务设置为任务类型，然后使用
语句。 您还可以使用“pragma Storage_Size(My_Task_Type_Name)”，但我认为“for”语句是首选。
最后，使用 Gnat，您还可以使用 -d 标志将默认任务堆栈大小更改为 gnatbind。
This is a total shot in the dark, but you can have tasks blow up like this at startup if they are trying to allocate too much local memory on the stack. Your main program can safely use the system stack, but tasks have to have their stack allocated at startup from dynamic memory, so typcially your runtime has a default stack size for tasks. If your task tries to allocate a large array, it can easily blow past that limit. I've had it happen to me before.
There are multiple ways to fix this. One way is to move all your task-local data into package global areas. Another is to dynamically allocate it all.
If you can figure out how much memory would be enough, you have a couple more options. You can make the task a task type, and then use a
statement. You can also use a "pragma Storage_Size(My_Task_Type_Name)", but I think the "for" statement is preferred.
Lastly, with Gnat you can also change the default task stack size with the -d flag to gnatbind.
我突然想到，如果代码是在 Sparc 机器上使用的，而您现在在 x86 机器上运行，则可能会遇到字节序问题。
这没有多大帮助，但这是多平台时的常见问题。
Off the top of my head, if the code was used on Sparc machines, and you're now runing on an x86 machine, you may be running into endian problems.
It's not much help, but it is a common gotcha when going multiplat.
预感：链接步骤不正确。 也许链接了错误的运行时启动库？
（问题提出几个月后，找出真正问题所在的可能性有多大？）
Hunch: the linking step didn't go right. Perhaps the wrong run-time startup library got linked in?
(How likely to find out what the real trouble was, months after the question was asked?)